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 @@
bar1
-xbar2
+ybar2
bar3
and in the reject file I have this view
$ cat bar.62852.00001.rej
***************
*** 1,3 ****
bar1
! bar2
bar3
--- 1,3 ----
bar1
! xbar2
bar3
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
history.]
--
Philip
---------------------------------------------------------------------
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