[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Patch command execution

From: Mo DeJong <supermo_at_bayarea.net>
Date: 2002-02-08 07:03:52 CET

On 07 Feb 2002 23:10:00 -0600
Karl Fogel <kfogel@newton.ch.collab.net> wrote:

...
 
> IMHO, we don't want to keep the .rej files. Let's use conflict
> markers instead, and use a timestamp to tell if the conflict should be
> considered resolved. I.e., if the file has been modified since it
> received the conflict, we assume the conflict is resolved. We don't
> check if conflict markers are present or absent -- that's too likely
> to prevent "valid" commits, and if we have the timestamp solution
> anyway, that's enough.
>
> Comments? Suggestions? Rotten fruit? :-)

Please don't do that. We don't want to leave conflict markers in files
because someone always screws up conflict resolution and you
end up with a bunch of <<<<<< characters in your files.
I am not joking, this happens all the time. Only those changes
that apply cleanly should be applied. This is a CVS mistake that
we should not make.

I also like the concept of a "conflict file", we only make use of a .rej file
right now, but that does not mean we could not do something more
useful. For example, what if you made some local modifications to
a file that had been deleted on the server. One might want that
to remove the file but keep it in a conflicted state without losing
your modifications. When the conflict is generated, we could
dump a message into the file describing what went wrong with the
file delete (you had local mods) and we could save the last diff in
there too. My point is that we have a lot of flexibility WRT what
could be put into the conflict marker file.

cheers
Mo DeJong

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.