You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Michael Klemm <mi...@informatik.uni-erlangen.de> on 2004/12/14 15:41:01 UTC
Request for Feature: svn resolved
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
I've got a little proposal to extend the features of "svn resolved".
When merging with some branches we get conflicts of files that were
never touched inside the destination for the merge.
Thus, the current way to resolve such conflicts is to simply cp the file
from the source branch "FooBar.cc.merge-right.rXXXXX" to the local file
"FooBar.cc". Doing this for more than 10 files is both error prone and
annoying.
Maybe svn resolved could do the job if the user was able to specify how
the conflict should be resvoled. I'd like to have additional options to
"svn resolved":
"svn resolved --mine FooBar.cc.mine" resolves the conflict in flavor of
the file FooBar.cc.mine (per cp'ing) and automatically sets the resolved
status of the file. The same applies to --right and --left to flavor the
version that comes from the source branch or the destination branch of
the merge.
Regards
-michael
- --
Computer Science Department 2, University of Erlangen-Nuremberg
Martensstrasse 3, D-91058 Erlangen, Germany
phone: ++49 (0)9131 85-28995, fax: ++49 (0)9131 85-28809
web: http://www2.informatik.uni-erlangen.de/~klemm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBvwmNWEu1syWqdn0RAm/+AJ4w73ZUtGjELmPCeDWs+V6lT35K5wCeL5yp
TE5iZxET/oLIZ6L/l5cwhvM=
=VvjN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Request for Feature: svn resolved
Posted by Michael Klemm <mi...@informatik.uni-erlangen.de>.
Hi Karl,
kfogel@collab.net wrote:
> I suggest taking it to the dev@ list, if you're feeling persistent,
> though. We're just three people, others may feel differently than we
> do.
I'll think I'll take it to the dev@ list for a vote. Let's what the
others think about that issue.
-michael
--
Computer Science Department 2, University of Erlangen-Nuremberg
Martensstrasse 3, D-91058 Erlangen, Germany
phone: ++49 (0)9131 85-28995, fax: ++49 (0)9131 85-28809
web: http://www2.informatik.uni-erlangen.de/~klemm
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Request for Feature: svn resolved
Posted by kf...@collab.net.
Michael Klemm <mi...@informatik.uni-erlangen.de> writes:
> I've got a little proposal to extend the features of "svn resolved".
> When merging with some branches we get conflicts of files that were
> never touched inside the destination for the merge.
>
> Thus, the current way to resolve such conflicts is to simply cp the file
> from the source branch "FooBar.cc.merge-right.rXXXXX" to the local file
> "FooBar.cc". Doing this for more than 10 files is both error prone and
> annoying.
I know that a lot of people have written simple wrapper scripts to
help with large-scale merges like this.
> Maybe svn resolved could do the job if the user was able to specify how
> the conflict should be resvoled. I'd like to have additional options to
> "svn resolved":
>
> "svn resolved --mine FooBar.cc.mine" resolves the conflict in flavor of
> the file FooBar.cc.mine (per cp'ing) and automatically sets the resolved
> status of the file. The same applies to --right and --left to flavor the
> version that comes from the source branch or the destination branch of
> the merge.
I talked it over with Mike Pilato and Ben Collins-Sussman here, and we
were skeptical that this is a good idea. Not definitively against,
just worried that a) it makes it too easy to shoot oneself in the
foot, and b) it's a lot of new options to make the user wade through.
Mike suggested a way around (b), by having
$ svn resolved --side [mine|left|right|query|whatever]
...but even with that change, I'm not sure he would support the idea.
I suggest taking it to the dev@ list, if you're feeling persistent,
though. We're just three people, others may feel differently than we
do.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Request for Feature: svn resolved
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 15, 2004, at 8:48 AM, Dale Worley wrote:
> I would assume that since Subversion knows the exact lineage of every
> line
> in every file that its merging algorithm would be a lot more
> sophisticated
> than "diff the two versions, apply the patch to the third version".
Nope. You assume incorrectly. 'svn merge -rX:Y' retrieves foo from
revision X, then retrieves foo from revision Y. It puts both files
into .svn/tmp/. Then it runs a 'diff3' algorithm on {tmpfile1,
tmpfile2, working file}. There's absolutely no "history sensitive"
merging going on.
This is one of the merge-tracking problems we need to solve someday...
see notes/merge-tracking.txt.
> (And if it doesn't, what's the point of keeping the history of file
> moves, etc.?)
>
The *repository* is definitely keeping track of history. That's why
'svn log foo.c' will trace through all the moves/renames of foo.c.
It's just that nobody's yet taught the 'svn merge' command to make use
of all that history.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Request for Feature: svn resolved
Posted by Dale Worley <dw...@pingtel.com>.
I would assume that since Subversion knows the exact lineage of every line
in every file that its merging algorithm would be a lot more sophisticated
than "diff the two versions, apply the patch to the third version". (And if
it doesn't, what's the point of keeping the history of file moves, etc.?)
Dale
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Conflicts don't just happen when 'svn merge' tries to patch an
already-modified file. A conflict can happen anytime a patch doesn't
apply cleanly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Request for Feature: svn resolved
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 14, 2004, at 10:39 AM, Dale Worley wrote:
> From: Michael Klemm [mailto:michael.klemm@informatik.uni-erlangen.de]
>> I've got a little proposal to extend the features of "svn resolved".
>> When merging with some branches we get conflicts of files that were
>> never touched inside the destination for the merge.
>
> It seems to me that you've got a bug here. If a file was not changed
> on one
> leg of the merge, svn should never report a conflict for it.
>
Conflicts don't just happen when 'svn merge' tries to patch an
already-modified file. A conflict can happen anytime a patch doesn't
apply cleanly.
If I ask 'svn merge' to compare two totally random versions of a file,
it's pretty easy to end up with a patch that doesn't apply cleanly to a
working file by the same name.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Request for Feature: svn resolved
Posted by Dale Worley <dw...@pingtel.com>.
From: Michael Klemm [mailto:michael.klemm@informatik.uni-erlangen.de]
> I've got a little proposal to extend the features of "svn resolved".
> When merging with some branches we get conflicts of files that were
> never touched inside the destination for the merge.
It seems to me that you've got a bug here. If a file was not changed on one
leg of the merge, svn should never report a conflict for it.
OTOH, it may be that some change has been made, albeit in an obscure way.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org