[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: Justin Erenkrantz <jerenkrantz_at_ebuilt.com>
Date: 2002-02-08 07:22:18 CET

On Thu, Feb 07, 2002 at 10:03:52PM -0800, Mo DeJong wrote:
> 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.

FWIW, I agree with Mo.

I hate the <<<<< chars. I'd rather have to deal with a .rej file.
I've never gotten it straight what was my changes and what was in
the repository. (Probably 'cause I always delete the <<<<
segment, re-checkout, and make my change again. I never spend
enough time dealing with it though to get it straight.)

Leaving the conflict in the file has already struck me as a sore
point. I think it's better to place the conflict in a separate
file in a unified diff format. Leave the local mods in the
local copy. And, perhaps not allow a commit if a .rej file
exists? -- justin

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.