RE: WinCvs install script and MarkResolved macro

> 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 ;)

Well, if you remember how this idea came into existence it is not *that* 
easy... There already exists the first obsolete Python macro 
(HideAdmin.py) as well...

 
> >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.

Well, my intention more or less was to "save the users from themselves", 
but OTOH you are probably correct that anyone who commits uncompilable 
code (because of remaining conflict markers) is not deserving of 
salvation... ;)

However, even though I did not test on really large files yet, my 
impression so far was that the performance hit of including the marker 
scan is not that big (remember that it is only performed on files that 
are already identified as Conflict and whose timestamp has changed 
since), so maybe I could change it so that the status will be reset on 
files with markers (which the macro will currently refuse to do) but 
with an appropriate warning in its report. Again OTOH, IIRC CVS will 
also display a warning when you commit a file that appears to still have 
conflict markers inside...

 
> >(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 know that it's regarded as resolved in the CVS sense but that does not 
necessarily mean that the conflict *is* resolved. Still, see above. You 
partly convinced me already.


> Let me explain. Here is the workflow example:
<.snip.>

Makes sense. It's obviously not what I had originally had in mind when I 
designed this. I'm still a bit indecisive about which idea I ultimately 
like better. I'd probably try to go for a "middle ground". See above.


> 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.

Yes, but only if you just view things from CVS' perspective. The new 
status based on comparing timestamps is an automatism that *could* 
produce false-positives (in the real-world sense). Maybe the user 
started to resolve conflicts but while doing so realized that the 
conflicts were too serious to be solved in a rush, so he has to delay 
the complete resolution until a later time. I intended to make a point 
of differentiating the automatic classification (where CVS says "I'd 
accept this if you told me to") from the fully conscious one where the 
*user* says "okay, now I'm done".

 
> 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.

Apart from the fact that it will currently refuse to mark files that 
still appear to contain conflict markers that's what it does now. I am 
considering to allow the marking but I'm hesitant to remove the scan.


> 2. Find all files containing the conflict markers in it's contents -
> regardless of the timestamp.

Yep. That's what it does now. The only thing I don't scan is unknown 
files...

I've still got more-than-usually time for macro work today, so if you 
reply quickly with your thoughts I could do the modifications right 
away, otherwise it just might have to wait for next week...

BTW: I don't know if you've started on the shell edit stuff already but 
I just *might* have time to tackle my todo list myself tomorrow night... 
the only thing I need to know for that is what would be the best place 
to put the ShellAction function in, given that it is to become 
cross-platform by Jens' request.

Cheers,

Oliver
----	------------------
JID:	[email protected]
ICQ:	18777742	(http://wwp.icq.com/18777742)


------------------------ 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/