You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dominik Psenner <dp...@gmail.com> on 2011/08/02 08:40:50 UTC
Strange behavior on directory delete/commit
Hi,
having a fresh subversion repository doing this as preparation:
$ mkdir foo/
$ svn add foo
$ svn commit -m "test"
Adding foo
Revision X sent.
$ rmdir foo
$ svn st
! foo
$ svn delete foo
D foo
And finally this command fails:
$ svn commit foo -m "fail"
svn: entry "foo" has no URL
This instead does work:
$ svn commit -m "works"
Delete foo
Revision X sent.
svn commit behaves inconsistently depending on whether a PATH argument is
given or not. If it is a bug, it should get at least priority P2 because one
is unable to commit partial changes to the WC as in this scenario:
$ mkdir foo/
$ svn add foo
A foo
$ svn commit -m "test"
Adding foo
Revision X sent.
$ rmdir foo
$ svn st
! foo
$ svn delete foo
D foo
$ touch bar
$ touch foobar
$ svn add bar foobar
A bar
A foobar
$ svn commit foo bar
svn: entry "foo" has no URL
To get things done, one would have to backup foobar somewhere, revert
foobar, do the commit without PATH arguments and copy foobar over to the WC.
*eek*
Let me know what you think about this!
Greetings,
D.
Re: Strange behavior on directory delete/commit
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Aug 03, 2011 at 11:27:48AM +0200, Dominik Psenner wrote:
> > You must still use svn commands instead of OS
> >commands in 1.7. That won't change. I don't think it will ever change.
> >The reason is that Subversion tracks operations explicitly, rather than
> >implicitly. In other words, Subversion needs to modify meta-data in
> >the .svn directory if you change something. If you run an OS-level
> >command the actual disk state and the meta-data get out of sync.
>
> *sarcastic* The user does not care what levers subversion needs to pull to
> show him what parts of a file were modified. */sarcastic*
File modifications are detected automatically. This is easy because
files have timestamps, and because Subversion has a pristine copy
of each file in the .svn directory. And there is no ambiguity -- a file
is either modified or it isn't.
But for tree changes, Subversion provides commands, and users must
use the commands to operate on the tree.
> The current working copy layout is unable to handle the usecase I described
> since it needs the missing meta-data that was stored within the deleted
> folder itself.
Yes, this is one use case that 1.7 fixes. You can now replace
directories without having to commit the deletion of the replaced
directory separately from the addition of the replacing directory.
E.g. you can delete a directory and move a different one on top:
$ svn rm epsilon
D epsilon
D epsilon/zeta
$ svn mv gamma epsilon
A epsilon
D gamma
D gamma/delta
$ svn status
D gamma
D gamma/delta
R + epsilon
D epsilon/zeta
and commit the result in a single revision:
------------------------------------------------------------------------
r3 | stsp | 2011-08-03 12:27:38 +0200 (Wed, 03 Aug 2011) | 1 line
Changed paths:
R /trunk/epsilon (from /trunk/gamma:2)
D /trunk/gamma
1.6 used to error out in the second step:
svn: Cannot copy to 'epsilon' as it is scheduled for deletion
RE: Strange behavior on directory delete/commit
Posted by Dominik Psenner <dp...@gmail.com>.
>[snip]
>> Subversion is still an observer and whatever a user does, he must tell
>> Subversion what he did in cases where subversion can't
>> understand it by
>> itself (i.e. file/folder rename/move that preserve history across the
>> revisions). Every VCS I know works like this. Maybe one invents a VCS
>
>Sort of. Mercurial is perfectly happy if you tell it afterwards (before a
>commit of course) that you renamed that file and deleted the other one.
>This behavior comes in handy, if you have to rename some files in the IDE,
>because only the IDE knows what (and in which file) has to be renamed...
It smells differently, but is basically the same. :-) But now I understand
what Stefan Sperling wanted to point out.
RE: Strange behavior on directory delete/commit
Posted by Andreas Tscharner <an...@metromec.ch>.
[snip]
> Subversion is still an observer and whatever a user does, he must tell
> Subversion what he did in cases where subversion can't
> understand it by
> itself (i.e. file/folder rename/move that preserve history across the
> revisions). Every VCS I know works like this. Maybe one invents a VCS
Sort of. Mercurial is perfectly happy if you tell it afterwards (before a commit of course) that you renamed that file and deleted the other one. This behavior comes in handy, if you have to rename some files in the IDE, because only the IDE knows what (and in which file) has to be renamed...
Best regards
Andreas
--
Andreas Tscharner <an...@metromec.ch>
----------------------------------------------------------------------
"Intruder on level one. All Aliens please proceed to level one."
-- Call in "Alien: Resurrection"
CT-Dienstleistungen neu bei Wenzel Metromec
===========================================
Haben Sie einen Prototyp ohne Zeichnung oder Konstruktionsmodell?
Suchen Sie in Ihren Bauteilen Materialschäden, Risse und Poren?
Dann sind unsere neuen Dienstleistungen im Bereich der Computertomographie die perfekte Lösung für Ihre Anforderungen!
Testen Sie uns und unsere neue WENZEL exaCT Anlage.
Zögern Sie nicht und nehmen Sie noch heute mit uns Kontakt auf.
mailto:ct@metromec.ch?subject=CT-Dienstleistungen
RE: Strange behavior on directory delete/commit
Posted by Dominik Psenner <dp...@gmail.com>.
>I'm not sure you understand the kinds problems the new working copy
>format is settling.
For me it settles the major problem of multiple .svn folders in a checkout.
> You must still use svn commands instead of OS
>commands in 1.7. That won't change. I don't think it will ever change.
>The reason is that Subversion tracks operations explicitly, rather than
>implicitly. In other words, Subversion needs to modify meta-data in
>the .svn directory if you change something. If you run an OS-level
>command the actual disk state and the meta-data get out of sync.
*sarcastic* The user does not care what levers subversion needs to pull to
show him what parts of a file were modified. */sarcastic*
>Subversion is not like git which goes "Woaaahh... I just woke up and
>now... what??? What did the user DO??? Well, whatever, I'm just gonna
>take a wild guess to deal with this and go back to bed..."
Please correct me if I'm wrong:
Subversion is still an observer and whatever a user does, he must tell
Subversion what he did in cases where subversion can't understand it by
itself (i.e. file/folder rename/move that preserve history across the
revisions). Every VCS I know works like this. Maybe one invents a VCS
filesystem that can hook into the filesystem operations, but that's
something that will be written on other papers. ;-)
Back to topic:
The current working copy layout is unable to handle the usecase I described
since it needs the missing meta-data that was stored within the deleted
folder itself. Thus Subversion < 1.7 would need a special logic to handle
these cases. One could discuss whether this should be fixed so that < 1.7
behaves on folder deletes just alike file deletes. I leave that decision up
to the devs since I'm unable to estimate the costs.
The new working copy layout does not have the meta-data within subfolders
and thus is able to commit just that change. HOORAY! This issue *can* be
solved with WC-NG without special logics!
--quote Ryan Schmidt--
I also have a feeling Subversion 1.7's new working copy arrangement will fix
or at least change this behavior.
--eof quote Ryan Schmidt--
Greetings,
D.
Re: Strange behavior on directory delete/commit
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Aug 03, 2011 at 10:25:07AM +0200, Dominik Psenner wrote:
> >Then you must explain it to them. :) To move or delete items in a working
> >copy, you must use svn commands. You must not use OS commands. That's just
> >how it is.
>
> This is going to be a long journey. *jokingly*
>
> Thanks for the insights and incredibly fast answers! It's awesome that
> you're working on the .svn meta-data folders problem. If you manage to get
> it settled, I believe 1.7.X is going to be great!
I'm not sure you understand the kinds problems the new working copy
format is settling. You must still use svn commands instead of OS
commands in 1.7. That won't change. I don't think it will ever change.
The reason is that Subversion tracks operations explicitly, rather than
implicitly. In other words, Subversion needs to modify meta-data in
the .svn directory if you change something. If you run an OS-level
command the actual disk state and the meta-data get out of sync.
Subversion is not like git which goes "Woaaahh... I just woke up and
now... what??? What did the user DO??? Well, whatever, I'm just gonna
take a wild guess to deal with this and go back to bed..."
Both approaches have advantages and disadvantages.
RE: Strange behavior on directory delete/commit
Posted by Dominik Psenner <dp...@gmail.com>.
>Then you must explain it to them. :) To move or delete items in a working
>copy, you must use svn commands. You must not use OS commands. That's just
>how it is.
This is going to be a long journey. *jokingly*
Thanks for the insights and incredibly fast answers! It's awesome that
you're working on the .svn meta-data folders problem. If you manage to get
it settled, I believe 1.7.X is going to be great!
Re: Strange behavior on directory delete/commit
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 3, 2011, at 03:17, Dominik Psenner wrote:
>> I doubt it. Or rather, the behavior is not broken. The user is broken. As I
>> said: "svn commit foo" should have worked fine if you had not run "rmdir
>> foo" beforehand. Don't run "rmdir foo". Just run "svn rm foo" followed by
>> "svn commit foo" and everything should work.
>
> True - it's nothing totally new to me. I just doubt the lusers who are going
> to use the frontend I'm writing for them understand the difference. :-)
Then you must explain it to them. :) To move or delete items in a working copy, you must use svn commands. You must not use OS commands. That's just how it is.
RE: Strange behavior on directory delete/commit
Posted by Dominik Psenner <dp...@gmail.com>.
>I doubt it. Or rather, the behavior is not broken. The user is broken. As I
>said: "svn commit foo" should have worked fine if you had not run "rmdir
>foo" beforehand. Don't run "rmdir foo". Just run "svn rm foo" followed by
>"svn commit foo" and everything should work.
True - it's nothing totally new to me. I just doubt the lusers who are going
to use the frontend I'm writing for them understand the difference. :-)
Re: Strange behavior on directory delete/commit
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 3, 2011, at 03:04, Dominik Psenner wrote:
>> I think "svn commit foo" would work fine, provided you do not "rmdir foo"
>> first; that was your error.
>>
>> I also have a feeling Subversion 1.7's new working copy arrangement will
>> fix or at least change this behavior.
>
> So there's still a light at the far end of the tunnel! :o) From what I've
> read just now 1.7.X's WC arrangement will become alike hg's way. I
> understand well that the current svn infrastructure is not suited for this
> usecase.
>
> Would patching svn 1.6.X to fix the behaviour be feasible?
I doubt it. Or rather, the behavior is not broken. The user is broken. As I said: "svn commit foo" should have worked fine if you had not run "rmdir foo" beforehand. Don't run "rmdir foo". Just run "svn rm foo" followed by "svn commit foo" and everything should work.
RE: Strange behavior on directory delete/commit
Posted by Dominik Psenner <dp...@gmail.com>.
>> I think SVN is behaving correctly. When you do svn commit foo you're
>telling Subversion to commit changes made in foo. There are no changes in
>foo because it's been deleted. The changes, instead, are in its parent
>directory, the one from where you issued your commands. That's why svn
>commi works, it assumes . as the path.
I disagree. Providing a PATH argument should tell svn that one wants to
commit the changes to "foo". In this case it would be that "foo" was
deleted. Since I want only the changes to "foo" to be versioned, it would
not make sense to include all other changes within the parent directory.
>I think "svn commit foo" would work fine, provided you do not "rmdir foo"
>first; that was your error.
>
>I also have a feeling Subversion 1.7's new working copy arrangement will
>fix or at least change this behavior.
So there's still a light at the far end of the tunnel! :o) From what I've
read just now 1.7.X's WC arrangement will become alike hg's way. I
understand well that the current svn infrastructure is not suited for this
usecase.
Would patching svn 1.6.X to fix the behaviour be feasible?
Re: Strange behavior on directory delete/commit
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 2, 2011, at 07:11, Giulio Troccoli wrote:
> On 02/08/11 07:40, Dominik Psenner wrote:
>>
>> having a fresh subversion repository doing this as preparation:
>>
>> $ mkdir foo/
>> $ svn add foo
>> $ svn commit -m "test"
>> Adding foo
>> Revision X sent.
>> $ rmdir foo
>> $ svn st
>> ! foo
>> $ svn delete foo
>> D foo
>>
>> And finally this command fails:
>>
>> $ svn commit foo -m "fail"
>> svn: entry "foo" has no URL
>>
> I think SVN is behaving correctly. When you do svn commit foo you're telling Subversion to commit changes made in foo. There are no changes in foo because it's been deleted. The changes, instead, are in its parent directory, the one from where you issued your commands. That's why svn commi works, it assumes . as the path.
I think "svn commit foo" would work fine, provided you do not "rmdir foo" first; that was your error.
I also have a feeling Subversion 1.7's new working copy arrangement will fix or at least change this behavior.
Re: Strange behavior on directory delete/commit
Posted by Giulio Troccoli <gi...@mediatelgroup.co.uk>.
On 02/08/11 07:40, Dominik Psenner wrote:
> Hi,
>
> having a fresh subversion repository doing this as preparation:
>
> $ mkdir foo/
> $ svn add foo
> $ svn commit -m "test"
> Adding foo
> Revision X sent.
> $ rmdir foo
> $ svn st
> ! foo
> $ svn delete foo
> D foo
>
> And finally this command fails:
>
> $ svn commit foo -m "fail"
> svn: entry "foo" has no URL
>
> This instead does work:
>
> $ svn commit -m "works"
> Delete foo
> Revision X sent.
>
> svn commit behaves inconsistently depending on whether a PATH argument is
> given or not. If it is a bug, it should get at least priority P2 because one
> is unable to commit partial changes to the WC as in this scenario:
>
> $ mkdir foo/
> $ svn add foo
> A foo
> $ svn commit -m "test"
> Adding foo
> Revision X sent.
> $ rmdir foo
> $ svn st
> ! foo
> $ svn delete foo
> D foo
> $ touch bar
> $ touch foobar
> $ svn add bar foobar
> A bar
> A foobar
> $ svn commit foo bar
> svn: entry "foo" has no URL
>
> To get things done, one would have to backup foobar somewhere, revert
> foobar, do the commit without PATH arguments and copy foobar over to the WC.
> *eek*
>
> Let me know what you think about this!
>
> Greetings,
> D.
>
I think SVN is behaving correctly. When you do svn commit foo you're
telling Subversion to commit changes made in foo. There are no changes
in foo because it's been deleted. The changes, instead, are in its
parent directory, the one from where you issued your commands. That's
why svn commi works, it assumes . as the path.
RE: Strange behavior on directory delete/commit
Posted by Dominik Psenner <dp...@gmail.com>.
>You could also delete the directory directly in the repository using "svn
>delete <url> -m <message>". This way you would avoid the problem of
>committing partial changes of your working copy.
.. which is just another workaround.
AW: Strange behavior on directory delete/commit
Posted by "Becker, Thomas" <Th...@torex.com>.
You could also delete the directory directly in the repository using "svn delete <url> -m <message>". This way you would avoid the problem of committing partial changes of your working copy.
Regards,
Thomas
-----Ursprüngliche Nachricht-----
Von: Dominik Psenner [mailto:dpsenner@gmail.com]
Gesendet: Dienstag, 2. August 2011 08:41
An: users@subversion.apache.org
Betreff: Strange behavior on directory delete/commit
[...]
To get things done, one would have to backup foobar somewhere, revert
foobar, do the commit without PATH arguments and copy foobar over to the WC.
*eek*
Let me know what you think about this!
Greetings,
D.
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions expressed
are solely those of the author and do not necessarily represent those of Torex
(Torex Group of Companies). If you are not the intended recipient of this email
and its attachments, you must take no action based upon them, nor must you copy
or show them to anyone. Please contact the sender if you believe you have received
this email in error.
Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschäftsführer: Stephen Callaghan, Martin Timmann.
.