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

RE: Re: Problems merging renamed file with contents changes

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-09-12 19:38:04 CEST

> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
>
> brane@xbc.nu writes:
> > The bigger problem is this:
>
> :-)
>
> I don't see that this is a "bigger" problem -- I think it's
> essentially the same as in updates. The problem with rename is that
> it has two targets, and the committer (or updater) could choose to
> commit (or update) just one of those targets. Making rename be two
> operations solved this problem.
>
> Let's not have the WC library committing targets that the user didn't
> ask to be committed, that'll be scary for users.
>

Well, of course, that makes perfect sense.

> > $ cd wc; ls -F
> > foo/ bar/
> > $ svn mv foo/qux bar/qux
> > $ svn st
> > D + foo/qux # The '+' here is "delete for rename"
> > A + bar/qux
> > $ cd foo
> > $ svn ci -m 'Committing half a rename?'
> >
> > (Note, the status output is just an example, I'm sure we can do
better.)
> >
> > We have to either forbid this scenario (unrealistic), or force the
> commit of
> > bar/qux even if the commit is in foo/, and that's a non-trivial
change
> in WC
> > management. A revert must also magically affect the other half of
the
> rename.
>
> I think if the user doesn't name bar/qux, then we must respect that.
> We should just forbid the commit, but tell the user to pass --force if
> they really want to do it (while warning them that this will break the
> atomic rename semantics and degrade to simple delete+copy). Of
> course, when all of the rename is inside one directory, this won't be
> an issue -- but we can handle the case where it's not inside one
> directory, too.
>

Blech. I don't like the idea of breaking up the conceptual move
operation.

Please have it be all or nothing. Delete+copy just causes problems the
user won't fully understand/grasp if you let them break the rename into
two separate chunks. All of these reasons are what we've been talking
about recently. Don't let the user screw themselves over.

> None of this requires major changes in libsvn_wc, fortunately. We
> just
>
> 1) Add some metadata to entries, so that an `schedule=add' or
> `schedule=delete' entry can also have a `renamed-from' or
> `renamed-to' attribute, giving the URL of the companion item.
>
> 2) make harvest_committables notice all items that are part of a
> rename, and check that the companion item is also part of that
> commit.
>

3) If companion items aren't part of the commit, then issue error, and
abort commit.

:)

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 12 19:38:48 2002

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

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