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

Re: [PATCH] Multiple WC copies/moves without intervening ci

From: Paul Burba <paulb_at_softlanding.com>
Date: 2006-07-27 14:37:31 CEST

"Ivan Zhakov" <chemodax@gmail.com> wrote on 07/25/2006 02:30:06 PM:

> On 7/25/06, Paul Burba <paulb@softlanding.com> wrote:
> > Daniel Rall <dlr@collab.net> wrote on 07/24/2006 07:53:26 PM:
> > > > Great, I've thought yesterday: might be as next step we should
> > > > added but not commited files/directories too? I mean:
> > > > $ touch foo
> > > > $ svn add foo
> > > > $ svn cp foo bar
> > >
> > > This sounds completely reasonable. I'd love to see this
> >
> > I'll look into this today.
> >
> I didn't test, but it should be enough just remove "Sanity check 2"
> and write tests of course.
> --
> Ivan Zhakov


Sorry, I wasn't able to look at this until yesterday afternoon. I'm
afraid it's not as simple as defeating sanity check 2 (i.e. in
copy_file_administratively(): /* Sanity check 2: You cannot make a copy of
something that's not in the repository unless it's a copy of an
uncommitted copy. */). Here are some of the problems I see:

1) An added file has no text base, so when copy_file_administratively()
tries to copy the pristine text base it fails.

2) If we are going to support copying an added file, it only makes sense
(?) to support the following as well:

  a) moving an added file
  b) copying an added directory
  c) moving an added directory

This isn't so much a problem, as an added complication.

3) If we move an added file how do we get rid of the add entry in the
source directory? It's not like moving a versioned item, we don't want
any evidence left behind in entries that something once existed there and
was scheduled for addition...do we? I suppose the equivalent of svn rm
--force will work...

Anyhow, I'm looking into this right now, hope to have some ideas shortly.

Paul B.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 27 14:39:59 2006

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.