Re: WinCvs install script and MarkResolved macro

Oliver,

>That's of course the (little) drawback of maintaining distinct groups
>of installable macros from the same source directory. The file names
>now have to be explicitly specified in the installer, so one has to make
>sure none are missed...

That isn't that much of the problem. It would be easier if you wrote the
Python replacements for all TCL macros - we could simply use the *.tcl
wildcard for the obsolete macros and *.py for the new ones ;)

>Good idea. We should hold back the "bare" installer until that
>is implemented, though.

I wil probably do that one just before we are ready for 1.3b15.

>I'd rather leave it in so I don't accidentally mark a file as
>resolved that isn't at least 99% sure to be so

As far as CVS is concerned conflict is resolved once the file if "touched"
and it's timestamp differs from the one in the conflict entry info. The
modification of Entries file is just a "quick hack" to allow easier conflict
resolution for the users without implementing it properly in the GUI code.
That means that for the reason of marking the files as resolved the
timestamp check should always be enought. Once the files is touched it can
be commited by CVS. You don't have to put more restrictions or additional
checks at this point and the GUI won't do that either. Just the timestamp
check.

>(there could of course in theory be unresolved conflicts without conflict
>markers if the person doing the resolving just removed the markers but
>not the conflict).

That means resolved conflict in the CVS sense because you have to save the
files to remove the markers.

>I'm actually still thinking of removing the recursive mechanism,
>so as to make it an even more conscious action: only explicitly
>selected files will be marked as resolved - in that case I could
>probably skip the marker-scanning indeed.

I was hoping that it will be totally automatic action really ;)

Let me explain. Here is the workflow example:
1. User updates his sandbox by using "cvs update" and gets conflicts.
2. He goes around and resolves the conflicts - that is he looks at the files
and at least "touches" the file so the timestamp is modified.
3. That makes the conflict resolved from CVS point of view (regardless the
conflict markers)
4. User get's annoyed and confused as to which conflicts he has resolved
already.
5. He installs CvsIn and creates the VC++ project and adds his files to it
and checks - all resolved conflicts are marked with "R" icon... Just kidding
;)
5. (really) He runs the "Mark resolved" macro which finds the resolved
conflicts and changes the entries files to help WinCvs to recognize the
fact. WinCvs no longer detects the conflict but thinks that the files is
simply modified. Crude but it does the job - user can continue to search and
resolve any remaining conflicts.
6. He commits.

As you can see there is no "brute force" approach - we do not artificially
convince CVS that conflict was resolved. We are just helping GUI to stop
seeing the resolved conflicts which enables the user to find and fix all
conflicts. That means we don't have to search for conflict markers - that's
what the second macro is for.

>- the indicator should not be labeled "Resolved" but rather "Resolving"
>or something like that - only files that were consciously marked as
>resolved by the user should be labeled thus.

From the above analisys you can see that the file is never in the
"resolving" state on the disk - it's either in conflict state or resolved
state.

>- introducing the "Resolving" state must also result in the exclusion of
>the "Conflict" state from the group of Committable states for the
>filters: CVS will *not* allow you to commit "real" conflict files.

Naturally. We will have to change the icon for conflict to indicate it's
special meaninng.

>>It could be called "Search CVS Conflict markers" or something similiar.
>>
> (...) It would basically be a "simulated" run of the macro I have now with
slightly
>reworded reports. Do you think that version of the macro should scan files
that are
>not reported as having conflicts (by the Entries API) as well?

Yes, it should scan all selection, both modified and unmodified files. We
want to know whether there are any conflict markers in the code. It may be
that our co-worker commited file with markers in it - it will be a normal,
unmodified file in every sandbox. To find that you have to scan all selected
files/folders.

To summarize, we would have two logical operations/macros:
1. Find and mark the resolved conflicts - checks the timestamp of all files
that have the conflict indicated in the entries file.
2. Find all files containing the conflict markers in it's contents -
regardless of the timestamp.

At least that is what I was imagining ;)

Best Regards,
Jerzy

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/