My understanding of why people leave conflict markers in files they
commit has nothing to do with not having any user intervention... CVS
won't just let you commit a file hasn't changed since an update with a
conflict in it. The problem I tend to see is people who notice one
change, fix it, and don't search for more. They then check in the last
2 conflict markers after fixing the first one or two. Having a file
with the conflict markers in them will only solve problems that occur
when the user fails to note the conflict notice, fails to notice any
conflict markers, and continues to stubbornly edit the file and commit
it. I can't believe that happens very often.
What _is_ getting to me is how everyone seems to think that conflict
resolution happens once in a blue moon. Most of what I do with CVS is
conflict resolution: when I merge changes that Fyodor made to nmap into
my repository (I keep a complex, semi-popular patch to nmap going) I am
sitting around just resolving conflicts for a while. It's hardly ever
that I do an update on our 3D engine repository that there isn't some
silly conflict.
The .rej style of conflicts I'm sure isn't nearly as bad on a Unix
machine, but on Windows it really, really sucks. Having the conflict
resolution markers in a separate file isn't that much better. It's just
too far removed to go and look at files when the files aren't available
from the project IDE. "OK, so private/ilengineer/Ops/MSIL/Call.h has a
conflict stored in private/ilengineer/Ops/MSIL/Call.h.rej... let's look
at that. OK, file... open... manually hit *.rej so I can open a text
file, browse to that location... damn, not syntax highlighted (wrong
extension), right click text window, properties, file editing mode to
C/C++, ok, make a change... wonder if that works... wait, can't figure
it out without compiling, rename the old version to a backup file (in
case I still need it), rename the new file to where the old one was,
load it from the actual location, attempt to compile, resolve changes,
AHHH... commit". Some of that can be avoided by doing the two rename
operations first, but there seemed to be some implicit assumption that
you'd be merging the conflicts in the .rej file before moving it over...
I really can't come up with a usage case where I wouldn't be wanting to
make those two renames every single time I have a conflict (and then
have to remember to go back and delete the file that I no longer need...
I never get around to doing that with CVS's little hidden original
files).
Also, what's this about not commiting when ".rej" files exist... doesn't
that sound kind of special case-y? What if I have files that end with
".rej" that I want to commit to my repository? If they are already
special cased, is there code to make sure they don't get added by
accident? A little more general: what happens on platforms that don't
support multiple extensions, or have hard upper limits on filenames?
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
-----Original Message-----
From: cmpilato@collab.net [mailto:cmpilato@collab.net]
Sent: Friday, February 08, 2002 9:00 AM
To: Philip Martin
Cc: dev@subversion.tigris.org
Subject: Re: Patch command execution
Philip Martin <philip@codematters.co.uk> writes:
...
That's correct. I means that conflict resolution is this simple:
edit out the conflict markers in working_file.00000.12345.rej
rm working_file
mv working_file.00000.12345.rej working_file
So it gives the same beautifully easy CVS conflict resolution
mechanism plus protection against checking in bogosity (without at
least some human intervention).
> Philip, who *likes* the current behaviour.
To each his (or her) own, of course. If I can ask without trying to
sound like I'm stirring an argument: how often do you have to resolve
conflicts in Subversion trees? I only know how often *I* have to do
so, and how painful it is.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006