"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
allow
> > > > 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
supported...
> >
> > 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
Ivan,
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