[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-02-08 16:48:37 CET

cmpilato@collab.net writes:

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

My experience of resolving conflicts is mainly with ClearCase, as I
don't yet have much stuff under Subversion control. ClearCase produces
conflicts during merges (it doesn't have an update command), and I
have spent a lot of time resolving those. The key to resolving them, I
have found, is to have all *three* versions, the original one, and the
two conflicting ones.

At present, when there is a conflict, Subversion gives me two views of
the problem, so when this happens

$ svn up
1 out of 1 hunk FAILED -- saving rejects to bar.62852.00001.rej
C ./bar
$ svn st
C ./bar

I have this view of the conflict:

$ svn diff bar
Index: ./bar
--- ./bar
+++ ./bar Fri Feb 8 15:10:07 2002
@@ -1,3 +1,3 @@

and in the reject file I have this view

$ cat bar.62852.00001.rej
*** 1,3 ****
! bar2
--- 1,3 ----
! xbar2

All three versions of the conflicting line are available. I think
your proposal means that only two of those are visible. Yes, the
third is available from the repository, but getting it is a little
tricky. I need to know the revision of the file I was using before I
ran 'svn up' and that requires recording it *before* invoking the
command - once I see the conflict it is too late. [One change I would
like to see to conflict reporting is to put the revision numbers into
the rej-file. Conflict resolution, like version control, is all about

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.