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

Re: Re: [Subclipse-users] Merge lost revisions

From: Mark Phippard <markphip_at_gmail.com>
Date: Sun, 24 Apr 2011 08:01:12 -0400

On Sun, Apr 24, 2011 at 6:43 AM, jcompagner <jcompagner_at_gmail.com> wrote:
> i thought this was a limitation of svn itself?

There are some tools that try to do it outside of these limitations.
I believe they do stuff similar to how a Revision Graph is done and
build up a database of all history and then use that to try to figure
out what commands to run to handle it. There is a command line tool
developed by one of CollabNet's customers that does this and I know
they use it in a very complex enviornment:


> I really find this the most annoying missing thing of svn if i can say that.
> for example the simple thing like:
> i change a file, and then an update comes in that did move the file,
> This should just work, the file should be moved and then updated (and
> if then there are line number conflicts then a merge conflict should
> happen but not before that)
> Or the other way around, if i move a file and then an update comes
> around from another that also has updated the file, it should just
> update it on the new position.

Correct, even this seemingly simple situations are not handled
automatically. I think my very first post to the Subversion users@
list when 1.0 came out was about this. FWIW, there has been a lot of
effort over the years put in to trying to do this but it is very
difficult/impossible on top of the current SVN design.

> I really hope that SVN1.7 (and subclipse), when it will come out, its
> already late according to there own roadmap, will fix these things
> else i think we will look to GIT again.
> Moving files around is just a normal day to day thing

SVN 1.7 will not address this issue. In 1.6 the concept of tree
conflicts was added and this brought small improvements. Prior to 1.6
SVN was just silent when these problems happened so you really had to
know what was going on yourself. Now a tree conflict is raised.
While annoying, they at least alert you to the problem and Subclipse
added tools for resolving tree conflicts that can walk you through
moving your changes to the renamed file. It is all still too awkward
compared to having SVN just handle it, but it is better than what
existed before.

Mark Phippard
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2011-04-24 14:01:14 CEST

This is an archived mail posted to the Subclipse Users mailing list.

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