You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ivan Zhakov <ch...@gmail.com> on 2005/12/01 15:19:53 UTC
[PATCH] Allow copy files that already copied
Hi!
Current libsvn_wc implementation disallow command sequence like this:
touch foo
svn add foo
svn ci
svn cp foo foo2
svn cp foo2 foo3
svn ci
I propose to allow this and make foo3 take foo's URL as copyfrom-url.
Look to attached patch.
Yes, I know it is bit confusing, but it is usefull, especially for refactoring.
[[
Allow copy/move files that already copied.
* subversion/libsvn_wc/copy.c:
(copy_file_administratively, copy_dir_administratively): Use
source's copyfrom-url and
copyfrom-rev instead of url and rev when copy already copied files.
]]
--
Ivan Zhakov
Re: [PATCH] Allow copy files that already copied
Posted by Ivan Zhakov <ch...@gmail.com>.
On 12/2/05, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> On Thu, 1 Dec 2005, Ivan Zhakov wrote:
>
> > Hi!
> > Current libsvn_wc implementation disallow command sequence like this:
> > touch foo
> > svn add foo
> > svn ci
> > svn cp foo foo2
> > svn cp foo2 foo3
> > svn ci
>
> I tried this patch, and copying a copyied file works fine. Moving a
> copied file, however, doesn't work unless --force is specified, because it
> thinks that the source of the move has local modifications. I wonder if
> that check should be changed in some way to allow this?
I didn't see reason for have "--force" option for move command,
because we didn't loose any change. We move changes to other place.
But this is separate question.
>
> Also, would you care to write some tests for this enhancement?
>
> I like the feature.
This patch only for idea proposal, as you see Ben against this
feature. Of course I create patch before commiting this change.
--
Ivan Zhakov
Re: [PATCH] Allow copy files that already copied
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 1 Dec 2005, Ivan Zhakov wrote:
> Hi!
> Current libsvn_wc implementation disallow command sequence like this:
> touch foo
> svn add foo
> svn ci
> svn cp foo foo2
> svn cp foo2 foo3
> svn ci
I tried this patch, and copying a copyied file works fine. Moving a
copied file, however, doesn't work unless --force is specified, because it
thinks that the source of the move has local modifications. I wonder if
that check should be changed in some way to allow this?
Also, would you care to write some tests for this enhancement?
I like the feature.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by Ivan Zhakov <ch...@gmail.com>.
On 12/2/05, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 12/1/05, Ivan Zhakov <ch...@gmail.com> wrote:
> > Hi!
> > Current libsvn_wc implementation disallow command sequence like this:
> > touch foo
> > svn add foo
> > svn ci
> > svn cp foo foo2
> > svn cp foo2 foo3
> > svn ci
> >
> > I propose to allow this and make foo3 take foo's URL as copyfrom-url.
> > Look to attached patch.
> > Yes, I know it is bit confusing, but it is usefull, especially for refactoring.
> >
>
> I don't have any objection to this, but I seem to recall that we had
> decided in the past not to allow such things. Perhaps someone can sum
> up the reasons behind it.
>
> As far as the patch itself goes, one minor thing. You have two places
> where you do this:
>
> + if (((src_entry->schedule == svn_wc_schedule_add) &&
> + (!src_entry->copied))
> + || (! src_entry->url))
>
> First off, you should be consistent in the space between the ! and the
> value. Second, perhaps this deserves to be made into a macro or
> something, since there are at least two places that need to be in sync
> with regard to this test.
Thanks, for pointing nits. I hope if feature will be approved, I
remove this check at all. And allow copy added files and directories
too.
--
Ivan Zhakov
Re: [PATCH] Allow copy files that already copied
Posted by Ivan Zhakov <ch...@gmail.com>.
On 12/2/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > I don't have any objection to this, but I seem to recall that we had
> > decided in the past not to allow such things. Perhaps someone can sum
> > up the reasons behind it.
>
> Look at the bottom of libsvn_wc/copy.c.
Yes, I have already read it. My point of view that this feature more
important that possible inconsistencies. Most common usage scenario is
Java and C# refactoring tools that renames files many times before
commit.
--
Ivan Zhakov
Re: [PATCH] Allow copy files that already copied
Posted by Ben Collins-Sussman <su...@red-bean.com>.
> I don't have any objection to this, but I seem to recall that we had
> decided in the past not to allow such things. Perhaps someone can sum
> up the reasons behind it.
Look at the bottom of libsvn_wc/copy.c.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 12/1/05, Ivan Zhakov <ch...@gmail.com> wrote:
> Hi!
> Current libsvn_wc implementation disallow command sequence like this:
> touch foo
> svn add foo
> svn ci
> svn cp foo foo2
> svn cp foo2 foo3
> svn ci
>
> I propose to allow this and make foo3 take foo's URL as copyfrom-url.
> Look to attached patch.
> Yes, I know it is bit confusing, but it is usefull, especially for refactoring.
>
I don't have any objection to this, but I seem to recall that we had
decided in the past not to allow such things. Perhaps someone can sum
up the reasons behind it.
As far as the patch itself goes, one minor thing. You have two places
where you do this:
+ if (((src_entry->schedule == svn_wc_schedule_add) &&
+ (!src_entry->copied))
+ || (! src_entry->url))
First off, you should be consistent in the space between the ! and the
value. Second, perhaps this deserves to be made into a macro or
something, since there are at least two places that need to be in sync
with regard to this test.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by Molle Bestefich <mo...@gmail.com>.
Julian Foad wrote:
> That's not a precise enough description,
> but I accept that it could probably be
> fairly simple and easy to understand.
Right. I suck at explaining these things.
Just in case anyone wants to know what I meant, I'll try again.
Skip this entire posting if you already get it or don't care.. Seriously! :-)
Re: [PATCH] Allow copy files that already copied
Posted by Julian Foad <ju...@btopenworld.com>.
Molle Bestefich wrote:
> Karl Fogel wrote:
>
>>I understand that this might make certain operations easier, but I
>>think we need solid theoretical grounding for any such change. Being
>>convenient (in some circumstances) is not the same as being correct.
>
> OTOH, it is ever so unambiguous from a user's POV. The rule would be
> that you can rename/copy+delete files locally all you want, and once
> you commit, the repo will reflect the files moved/copied as per the
> time you do the commit. Easy to understand.
That's not a precise enough description, but I accept that it could probably be
fairly simple and easy to understand.
> Also there's nothing technically hindering this functionality, so
> there's no good reason to disallow it.
[...]
You know, I'm really persuaded by Molle's arguments about how it would make
sense and save a lot of trouble for users, and I think we can come up with a
clean and logical specification for it.
First, note the two major approaches:
1) Make the second copy/move refer to the source of the first one.
2) Make the second copy/move refer to the intermediate URL that does not yet
exist (at least not with the required content) in the repository.
Approach (1) makes the behaviour just an issue of user-interface semantics on
the client, and this is what I will consider here.
Approach (2) requires the server to support copies from the current revision.
This is also worth considering, as there is a chance that it may be easy
(already there) and well-defined.
Examine this "Rabbinic Commentary" from subversion/libsvn_wc/copy.c:
> Q: Why can't we 'svn cp' something that we just copied?
> i.e. 'svn cp foo foo2; svn cp foo2 foo3"
>
> A: It leads to inconsistencies.
>
> In the example above, foo2 has no associated repository URL,
> because it hasn't been committed yet. But suppose foo3 simply
> inherited foo's URL (i.e. foo3 'pointed' to foo as a copy
> ancestor by virtue of transitivity.)
>
> For one, this is not what the user would expect. That's
> certainly not what the user typed!
On the contrary, the user gets an exact copy of the file and user properties
that he/she asked for; only a piece of system meta-data differs. Making that
acceptable is simply a matter of client education. As well as explaining it in
the book and the help, we could issue a warning or information message saying
something like "The copy source will be recorded as '%s' because the specified
source '%s' is not yet committed".
> Second, suppose that the
> user did a commit between the two 'svn cp' commands. Now foo3
> really *would* point to foo2, but without that commit, it
> pointed to foo. Ugly inconsistency, and the user has no idea
> that foo3's ancestor would be different in each case.
The "no idea" was solved above. The "inconsistency" is really not much of a
problem. There are plenty of situations where an intermediate commit affects
the result of a local operation, e.g.
svn rm dir
svn cp dir dir2
succeeds whereas, with an intermediate commit, it would fail. (Maybe the
current success is a bug.) There are also already cases where an intermediate
commit can change the committed result of a subsequent operation in terms of
metadata, ancestry, etc.
svn cp file-with-local-changes foo2
locally change foo2
svn commit
This would record the two sets of changes to foo2 separably if an intermediate
commit were made, but as a single set of changes otherwise.
These situations can be called "ugly", but really they are just natural
consequences of the process and I don't imagine they really cause special
problems for users.
> And even if somehow we *could* make foo3 point to foo2 before
> foo2 existed in the repository... what's to prevent a user from
> committing foo3 first? That would break.
This could be handled. Here's one way: write the "copyfrom" source as "foo2"
in the WC initially, and at commit time see whether "foo2" is available (in the
repository or in the commit) and, if not, then follow the copyfrom source back
a step until reaching an item that is available. ("Yuck! What indeterminism!"
you cry.) Here's another way: disallow the commit if the copyfrom source isn't
available in it. That is analogous to what we may well do for true renames:
disallow a commit of one half of the rename. (In fact, we probably ought to
start doing that now, to move closer towards true rename semantics.)
OK, I haven't presented a specification or examined all the avenues, but I
think this could well be done.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied - old discussion
Posted by Folker Schamel <sc...@spinor.com>.
An old discussion about this topic:
http://svn.haxx.se/dev/archive-2005-01/0339.shtml
Especially I think that the scenario I described in
http://svn.haxx.se/dev/archive-2005-01/0358.shtml
is a good reason for supporting it.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied - second old discussion
Posted by Folker Schamel <sc...@spinor.com>.
Some other old discussion:
http://svn.haxx.se/users/archive-2003-12/0687.shtml
(This discussion also goes into some details
about the question what the right copy-from URL is.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Allow copy files that already copied
Posted by Folker Schamel <sc...@spinor.com>.
Molle Bestefich wrote:
> Folker Schamel wrote:
>
>>http://svn.haxx.se/users/archive-2003-12/0687.shtml
>
>
> I agree with that particular posting.
> Especially I think that this:
>
> "Another practical aspect is that you cannot move
> a directory and then afterwards rename files within
> this directory without an intermediate commit."
>
> is a very good point for supporting multiple cp/mv.
>
>
>
>>(This discussion also goes into some details
>>about the question what the right copy-from URL is.)
>
>
> Haven't read the entire thread :-).
>
> Since repository recording time is by definition the time when you do
> 'svn commit', any intermediate change in the working copy should not
> be reflected. Only the final state of the working copy compared to
> the previous state in the repository should be reflected in the
> commit.
>
> With that in mind, I don't imagine it's hard to define what the
> correct copy-from should be. Or is it?
Thats also my view :-)
I cannot speak for others, but my impression was that
this was also the agreement after this discussion.
>>Especially I think that the scenario I described in
>>http://svn.haxx.se/dev/archive-2005-01/0358.shtml
>>is a good reason for supporting it.
>
>
> I don't think so, the whole premise of the scenario is false.
> TortoiseSVN supports moving foo/foo.cpp -> tau/tau.cpp just fine.
> Just right-click foo.cpp, select "Rename..." then enter "../tau/tau.cpp".
Ups, I didn't know that!
But nevertheless, the scenario remains valid.
(The only thing which changes is that you can use TSVN for all these steps.)
Note that this scenario is just a sample for renaming a file
in a moved folder as you mentioned above.
Cheers,
Folker
> (The menu item should probably be renamed to "Move/Rename ..." to
> lessen confusion.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Allow copy files that already copied
Posted by Molle Bestefich <mo...@gmail.com>.
Folker Schamel wrote:
> http://svn.haxx.se/users/archive-2003-12/0687.shtml
I agree with that particular posting.
Especially I think that this:
"Another practical aspect is that you cannot move
a directory and then afterwards rename files within
this directory without an intermediate commit."
is a very good point for supporting multiple cp/mv.
> (This discussion also goes into some details
> about the question what the right copy-from URL is.)
Haven't read the entire thread :-).
Since repository recording time is by definition the time when you do
'svn commit', any intermediate change in the working copy should not
be reflected. Only the final state of the working copy compared to
the previous state in the repository should be reflected in the
commit.
With that in mind, I don't imagine it's hard to define what the
correct copy-from should be. Or is it?
> Especially I think that the scenario I described in
> http://svn.haxx.se/dev/archive-2005-01/0358.shtml
> is a good reason for supporting it.
I don't think so, the whole premise of the scenario is false.
TortoiseSVN supports moving foo/foo.cpp -> tau/tau.cpp just fine.
Just right-click foo.cpp, select "Rename..." then enter "../tau/tau.cpp".
(The menu item should probably be renamed to "Move/Rename ..." to
lessen confusion.)
> An old discussion about this topic:
> http://svn.haxx.se/dev/archive-2005-01/0339.shtml
Interesting.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by Molle Bestefich <mo...@gmail.com>.
Karl Fogel wrote:
> Molle Bestefich writes:
> > Scenarios:
> > 1.) You accidentally rename 'abc' to 'dex' instead of 'def'.
> > 2.) You accidentally rename 'abg' to 'def' instead of 'abc' to 'def'.
> > 3.) You accidentally copy 'abc' to 'dex' instead of 'def'.
> > 4.) ... etc ...
[snip explanation]
> If we fixed revert to Do The Right Thing,
> would that solve the problem?
For the scenarios mentioned, yes.
To be helpful towards newbies, it (c/sh)ould be decided that:
# svn mv a b
# svn mv b a
(eg. rename, rename back) is not an action that anyone would like to
actually record in their repository. So while we're making 'svn
revert' Do The Right Thing, we might as well make this action do the
same.
Then the scenarios mentioned would be elegantly fixed, both for those
who knows 'svn revert' and for newbies who think "I'll just move the
file back" as a first impulse.
> > He's getting more confused. Then he tries to svn revert the original
> > file instead:
> > # svn revert abc
> > Reverted 'abc'
> >
> > Only to find that now he has TWO files - both the original and the
> > moved-to file:
> > # ls
> > abc
> > dex
>
> And this should do the same thing, IMHO.
Agree.
> In other words, if we made these recovery steps work right, that would
> solve most of the problem, no?
That would definitely be a lot prettier than what's there now :-).
Michael Brouwer wrote:
> Disallowing multiple svn cp or svn mv commands on already copied or
> moved files is still not orthogonal to how the normal cp and mv
> commands work.
Agree.
> So to truly solve the problem of people seeing
> unexpected errors you'd need to allow for those types of operations in
> a wc.
Agree.
> it might not be worth the effort by itself, but from a consistency and
> ease of use point of view allowing what Molle outlined would make
> sense.
Agree.
> That said this might be a lot more work than just changing revert, and
Ivan has already coded it up it seems.
I think his approach is sane, except that:
1. svn cp a b
2. echo "Now here's a change to file B" >> b
3. svn cp b c
4. echo "And here's a change to file C" >> c
5. svn ci
6. svn diff c -rPREV:HEAD
The diff on C will be wrong. It will show the change performed in
step 2 as a change to file C, while the change was actually to file B.
The user will never want this.
If Ivan's patch is accepted, an added restriction should be that the
source file must not be an already copied file with local
modifications.
(If a user really wants (?!), --force could be considered an option.)
I realize that the same problem exists with current svn. Consider:
1. echo "Here's a change to the WC file A" >> a
2. svn cp a b
3. echo "Here's a change to the WC file B" >> b
4. svn ci
5. svn diff b -rPREV:HEAD
This is currently allowed and will not do what a regular user expects.
The copy-from will be file A at the revision *before* the commit in
step 4 and thus the changes made in step 1 will appear both as changes
to A, and as separate changes to B.
The reason that this hasn't been explicitly disallowed is (I think)
that few people actually modify a file and then copy it around because
there's currently not much use of doing so.
But I think there's a high risk that more people are going to do this
if multiple consecutive svn cp/mv is allowed as by Ivan's patch.
So this problem should probably be addressed now too.
I'm not trying to overreact or anything, just think ahead :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by Michael Brouwer <mb...@gmail.com>.
Disallowing multiple svn cp or svn mv commands on already copied or
moved files is still not orthogonal to how the normal cp and mv
commands work. So to truly solve the problem of people seeing
unexpected errors you'd need to allow for those types of operations in
a wc.
That said this might be a lot more work than just changing revert, and
it might not be worth the effort by itself, but from a consistency and
ease of use point of view allowing what Molle outlined would make
sense.
Michael
On 19 Dec 2005 14:18:26 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> Molle Bestefich <mo...@gmail.com> writes:
> > Scenarios:
> > 1.) You accidentally rename 'abc' to 'dex' instead of 'def'.
> > 2.) You accidentally rename 'abg' to 'def' instead of 'abc' to 'def'.
> > 3.) You accidentally copy 'abc' to 'dex' instead of 'def'.
> > 4.) ... etc ...
> >
> > We'll start with 1).
> > # svn mv abc dex
> >
> > Oops, should've been 'def'. It now seems very obvious (user POV) to
> > undo the move by 'svn mv'ing the file to a correct filename:
> > # svn mv dex def
> > svn: Use --force to override this restriction
> > svn: Move will not be attempted unless forced
> > svn: 'dex' has local modifications
> >
> > That fails, with an unrelated and therefore very poor error message
> > (local mods?!).
> >
> > The user might then try to 'svn revert'. He's a bit confused now,
> > because which file should be the target of svn revert - the renamed
> > one or the original one?
> >
> > He tries the renamed one first since it actually exists in his filesystem:
> > # svn revert dex
> > Reverted 'dex'
> >
> > Only to find that it does not accomplish what he expects (renaming the
> > file back). Judging from the above output, it actually looks like it
> > reverted 'half' of the rename, eg. the addition of dex, but did not
> > undo the removal of 'abc'. If he has local mods, he'll be very
> > worried, but let's assume for now that he hasn't and it's OK that
> > 'dex' is gone. He now does a regular 'ls' but sees that 'dex' is
> > still there:
> > # ls
> > dex
>
> If we fixed revert to Do The Right Thing, would that solve the
> problem?
>
> > He's getting more confused. Then he tries to svn revert the original
> > file instead:
> > # svn revert abc
> > Reverted 'abc'
> >
> > Only to find that now he has TWO files - both the original and the
> > moved-to file:
> > # ls
> > abc
> > dex
>
> And this should do the same thing, IMHO.
>
> In other words, if we made these recovery steps work right, that would
> solve most of the problem, no?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: [PATCH] Allow copy files that already copied
Posted by kf...@collab.net.
Molle Bestefich <mo...@gmail.com> writes:
> Scenarios:
> 1.) You accidentally rename 'abc' to 'dex' instead of 'def'.
> 2.) You accidentally rename 'abg' to 'def' instead of 'abc' to 'def'.
> 3.) You accidentally copy 'abc' to 'dex' instead of 'def'.
> 4.) ... etc ...
>
> We'll start with 1).
> # svn mv abc dex
>
> Oops, should've been 'def'. It now seems very obvious (user POV) to
> undo the move by 'svn mv'ing the file to a correct filename:
> # svn mv dex def
> svn: Use --force to override this restriction
> svn: Move will not be attempted unless forced
> svn: 'dex' has local modifications
>
> That fails, with an unrelated and therefore very poor error message
> (local mods?!).
>
> The user might then try to 'svn revert'. He's a bit confused now,
> because which file should be the target of svn revert - the renamed
> one or the original one?
>
> He tries the renamed one first since it actually exists in his filesystem:
> # svn revert dex
> Reverted 'dex'
>
> Only to find that it does not accomplish what he expects (renaming the
> file back). Judging from the above output, it actually looks like it
> reverted 'half' of the rename, eg. the addition of dex, but did not
> undo the removal of 'abc'. If he has local mods, he'll be very
> worried, but let's assume for now that he hasn't and it's OK that
> 'dex' is gone. He now does a regular 'ls' but sees that 'dex' is
> still there:
> # ls
> dex
If we fixed revert to Do The Right Thing, would that solve the
problem?
> He's getting more confused. Then he tries to svn revert the original
> file instead:
> # svn revert abc
> Reverted 'abc'
>
> Only to find that now he has TWO files - both the original and the
> moved-to file:
> # ls
> abc
> dex
And this should do the same thing, IMHO.
In other words, if we made these recovery steps work right, that would
solve most of the problem, no?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by Molle Bestefich <mo...@gmail.com>.
Karl Fogel wrote:
> I understand that this might make certain operations easier, but I
> think we need solid theoretical grounding for any such change. Being
> convenient (in some circumstances) is not the same as being correct.
OTOH, it is ever so unambiguous from a user's POV. The rule would be
that you can rename/copy+delete files locally all you want, and once
you commit, the repo will reflect the files moved/copied as per the
time you do the commit. Easy to understand.
Also there's nothing technically hindering this functionality, so
there's no good reason to disallow it.
Also, the current state of consecutive svn cp/mv will quickly lead a
user to think his WC is busted every time he accidentally renames a
file wrong, which will make him dislike Subversion in the long run.
Here's an explanation of that scenario.
Scenarios:
1.) You accidentally rename 'abc' to 'dex' instead of 'def'.
2.) You accidentally rename 'abg' to 'def' instead of 'abc' to 'def'.
3.) You accidentally copy 'abc' to 'dex' instead of 'def'.
4.) ... etc ...
We'll start with 1).
# svn mv abc dex
Oops, should've been 'def'. It now seems very obvious (user POV) to
undo the move by 'svn mv'ing the file to a correct filename:
# svn mv dex def
svn: Use --force to override this restriction
svn: Move will not be attempted unless forced
svn: 'dex' has local modifications
That fails, with an unrelated and therefore very poor error message
(local mods?!).
The user might then try to 'svn revert'. He's a bit confused now,
because which file should be the target of svn revert - the renamed
one or the original one?
He tries the renamed one first since it actually exists in his filesystem:
# svn revert dex
Reverted 'dex'
Only to find that it does not accomplish what he expects (renaming the
file back). Judging from the above output, it actually looks like it
reverted 'half' of the rename, eg. the addition of dex, but did not
undo the removal of 'abc'. If he has local mods, he'll be very
worried, but let's assume for now that he hasn't and it's OK that
'dex' is gone. He now does a regular 'ls' but sees that 'dex' is
still there:
# ls
dex
He's getting more confused. Then he tries to svn revert the original
file instead:
# svn revert abc
Reverted 'abc'
Only to find that now he has TWO files - both the original and the
moved-to file:
# ls
abc
dex
Most users will now give up and do one of two things:
a.) Nuke the entire working copy and check out a new one. Most will
probably do this, and go on to be very annoyed about how ungracefully
Subversion handles a wrong file rename.
b.) If user has local changes that he does not wish to be lost, he'll probably:
b.1.) Commit whatever state his WC is in, then clean things up in a
later commit.
b.2.) Check out a new working copy, start copying individual modified
files (but not the ones affected by his svn mv) over from the old one,
to create a good WC.
All of the above solutions leaves a pretty bad impression. Simply
allowing consecutive svn cp/mv in a working copy obviously makes the
problem go away.
Another practicality is that allowing consecutive svn cp/mv would give
Subversion clients and scripts fewer error situations to handle, which
is always a good thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by Aleksey Nogin <al...@nogin.org>.
On 02.12.2005 15:10, kfogel@collab.net wrote:
> Ivan Zhakov <ch...@gmail.com> writes:
>
>>Current libsvn_wc implementation disallow command sequence like this:
>>touch foo
>>svn add foo
>>svn ci
>>svn cp foo foo2
>>svn cp foo2 foo3
>>svn ci
>>
>>I propose to allow this and make foo3 take foo's URL as copyfrom-url.
>
>
> Hmmm. But why is that correct? foo3's copyfrom-url is not foo's URL,
> it's foo2's (but foo2 doesn't have a URL yet, really, so that's not
> quite right either).
Well, consider the above example, where both "svn cp" are replaced with
"svn mv". In that case, as far as the repository is concerned, foo2
never existed and using foo as copyfrom-url makes perfect sense.
--
Aleksey Nogin
Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Moore 04, tel: (626) 395-2200
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by Jim Blandy <ji...@red-bean.com>.
On 02 Dec 2005 17:10:52 -0600, kfogel@collab.net <kf...@collab.net> wrote:
> > I propose to allow this and make foo3 take foo's URL as copyfrom-url.
>
> Hmmm. But why is that correct? foo3's copyfrom-url is not foo's URL,
> it's foo2's (but foo2 doesn't have a URL yet, really, so that's not
> quite right either).
>
> > Look to attached patch.
> > Yes, I know it is bit confusing, but it is usefull, especially for
> > refactoring.
>
> I understand that this might make certain operations easier, but I
> think we need solid theoretical grounding for any such change. Being
> convenient (in some circumstances) is not the same as being correct.
The same thing came up in the conversation about Garrett's new replay
function. Greg Hudson said that Subversion deltas weren't composable.
Given:
r1: add foo (no history)
r2: delete foo
r3: add foo (copy history foo@1)
r4: add bar (copy history foo@1)
Greg challenged me to describe the composition of r1 -- r4. I said:
If 'copy with history' could refer to a file added in the same delta,
the composition would be:
- add foo (no history)
- add bar (copied from our new foo)
Notice that the answer here also involves history referring to things
in the current transaction. Now Ivan has pointed out that these
histories actually occur in normal working copies, too. So even
uncomposed deltas already have such things going on, or would, if we
didn't forbid it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Allow copy files that already copied
Posted by kf...@collab.net.
Ivan Zhakov <ch...@gmail.com> writes:
> Current libsvn_wc implementation disallow command sequence like this:
> touch foo
> svn add foo
> svn ci
> svn cp foo foo2
> svn cp foo2 foo3
> svn ci
>
> I propose to allow this and make foo3 take foo's URL as copyfrom-url.
Hmmm. But why is that correct? foo3's copyfrom-url is not foo's URL,
it's foo2's (but foo2 doesn't have a URL yet, really, so that's not
quite right either).
> Look to attached patch.
> Yes, I know it is bit confusing, but it is usefull, especially for
> refactoring.
I understand that this might make certain operations easier, but I
think we need solid theoretical grounding for any such change. Being
convenient (in some circumstances) is not the same as being correct.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org