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

Re: Faulty merge logic?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-06-08 22:49:41 CEST

On Jun 8, 2005, at 12:32 PM, Carl Youngblood wrote:

> Forgive me if this has already been posted to this list, but I
> recently came across a blog entry considering different version
> control systems:
> http://www.simplicidade.org/notes/archives/2004/11/
> evaluating_sour.html
> One section especially caught my attention:
> "While evaluating these systems, I developed a small test to see if
> it's good enough for me:
> create two branches of a project, called B1 and B2;
> modify file X in B1;
> in B2, rename file X to Y;
> merge B1 into B2.
> If after these simple steps, your Y file does not have the
> modifications made in B1, the source control system is flawed, and I
> just can't use it. If you are serious about source control, this is
> just not acceptable.
> The interesting part is that it seems Subversion fails this simple
> test. I think I'm doing something wrong, I'm trying to see what, but I
> can't get Subversion to do the right thing. This would remove it from
> my list, and I would like to use Subversion (JabberStudio uses it a
> lot now)."
> Is this still true, and if so, is this a valid complaint, in your
> opinion?

Subversion doesn't have true moves, it has copies and deletes, and
the server currently doesn't broadcast copies to the client. We're
working on fixing it, mainly by implementing true moves.

In the meantime, here's another similar issue that explains what
you're seeing:


In other words, the server is sending a delete + add, rather than a

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 8 22:53:11 2005

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

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