RE: Strange behavior on directory delete/commit
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.
RE: Strange behavior on directory delete/commit
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
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
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
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
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
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
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
[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 andreas.tschar...@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:c...@metromec.ch?subject=CT-Dienstleistungen
RE: Strange behavior on directory delete/commit
[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
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
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.
AW: Strange behavior on directory delete/commit
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:dpsen...@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. .
Re: Strange behavior on directory delete/commit
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
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 Dfoo 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.
