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

Re: Questions on moving files and directories

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-04-22 22:05:25 CEST

On Apr 22, 2005, at 2:37 PM, Ingo Adler wrote:

>
> When "true renames" are implemented - what's the situation of the
> second committer? Wouldn't he have conflicts anyway or would you
> silently merge the changes in the new destination? What about deletes?
>

It means that when you run 'svn up', the server actually sends a "move"
command, not "delete & add" commands. So if your file is locally
edited, it gets moved, and now the file is still locally edited under
the new name.

But you're right, this still doesn't solve the "update tries to delete
my edited file" problem. The fact that your edited file becomes
unversioned can really be a shock to a coder -- it's too easy not to
notice that it happens.

The real reason we've not yet done the "tree conflict" solution is
because it gets very complex once you start talking about directories.
For example, what if the update tries to delete some parent directory
of your edited file? Do we set the whole directory into a state of
conflict? How far can the update run before bailing out? Our 1.0
solution was to bail completely on the problem and just "make
everything unversioned." But you're right, I think it's time to do
better.

kfogel and I have discussed this for the last 30 mins now, and we're
definitely going to file an issue on this. As ghudson says, "we
shouldn't let the perfect be the enemy of the good." We can certainly
solve a chunk of the problem by marking individual files as
(C)onflicted. It will take a bit of design work.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 22 22:08:01 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.