Re: copying subdirectories in subversion 1.7
Markus Schaber wrote on Tue, Jul 26, 2011 at 09:11:57 +0200: Von: Daniel Shahaf Perhaps you'd be interested in contributing to the implementation of this feature? Yes, I am, but I've only very limited time to work on it while being at home. I see. Hope you find the time for it :)
Re: copying subdirectories in subversion 1.7
Guten Tag Stefan Sperling, am Montag, 25. Juli 2011 um 00:22 schrieben Sie: http://subversion.tigris.org/issues/show_bug.cgi?id=2884 As the target of this enhancement is 1.8-consider and the last comment questions the need of this features in general, should one vote for the enhancement? Or is it better to wait until 1.7 and see how people may live with WC-NG? I really often just copy subdirs todays, for example. You can also keep using 1.6.x for the time being if detaching subdirectories is very important to you. 1.6.x is still going to supported until 1.8.0 is released. The interesting things are the tools, there surely won't be a Tortoise version with current bug fixes and versions 1.6.x of the svn libraries. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 09:03:05AM +0200, Thorsten Schöning wrote: Guten Tag Stefan Sperling, am Montag, 25. Juli 2011 um 00:22 schrieben Sie: http://subversion.tigris.org/issues/show_bug.cgi?id=2884 As the target of this enhancement is 1.8-consider and the last comment questions the need of this features in general, should one vote for the enhancement? Or is it better to wait until 1.7 and see how people may live with WC-NG? I really often just copy subdirs todays, for example. Honestly, we simply don't know how many people need this. You could add yourself to the Cc field in the issue tracker to signal that you are interested in this. We should also add a link to this thread in the archives from the issue tracker. I should mention that the best option is of course, surprise, sending patches :) If you've ever been curious about finding out how Subversion's working copy really works, know C, and have some spare time, this would be an interesting task to tackle, even for a new developer. The developer community is very friendly and helpful. So you won't be on your own. Note that since 1.7.x has been branched work on this feature could be started on trunk right now. I am not aware of any existing developer who expressed interest in working on 'svn detach'. But if enough people register their need for this feature it might happen. I myself want to work on something I (and I hope others, too) consider more important -- better support for local moves, see http://svn.apache.org/repos/asf/subversion/trunk/notes/moves
Re: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 10:37:36AM +0200, Markus Schaber wrote: Hi, Stefan, Von: Stefan Sperling [mailto:s...@elego.de] [Detaching of subdirectories of working copies] Honestly, we simply don't know how many people need this. Strictly speaking, it is not needed by anyone - one can always use a fresh checkout, and then manually merge all the changes. 1.7 has 'svn patch' so transferring local changes to a new checkout can be done in an automated way. cd ~/wc/subtree svn diff /tmp/subtree-changes.diff cd ~ svn co $URL/subtree other_wc svn patch /tmp/subtree-changes.diff other_wc This works fine even for new directories, deleted ones, etc. Caveat: It cannot do copies yet -- those will show up as simple adds. But in my experience, a lot of users (including me) actually made use of the copying a subdir just works pattern. Good to know. But note that it doesn't always work as expected in 1.6.x, even. Quoting the first comment in http://subversion.tigris.org/issues/show_bug.cgi?id=2884 you can't just copy a subtree of the added dir and expect it to work without its parent. This is a consequence of the fact the feature is accidental. Some edge cases just do not work because the feature hasn't actually been designed and implemented. It just happens to work most of the time.
Re: copying subdirectories in subversion 1.7
On 7/25/11 3:22 AM, Stefan Sperling wrote: I am not aware of any existing developer who expressed interest in working on 'svn detach'. Just curious: what drove the original WC design where each subdirectory was inherently independent? And is this the same set of developers? -- Les Mikesell lesmikes...@gmail.com
Re: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 02:27:04PM +0200, Markus Schaber wrote: Hi, Stefan, Von: Stefan Sperling [mailto:s...@elego.de] On Mon, Jul 25, 2011 at 10:37:36AM +0200, Markus Schaber wrote: Hi, Stefan, Von: Stefan Sperling [mailto:s...@elego.de] [Detaching of subdirectories of working copies] Honestly, we simply don't know how many people need this. Strictly speaking, it is not needed by anyone - one can always use a fresh checkout, and then manually merge all the changes. 1.7 has 'svn patch' so transferring local changes to a new checkout can be done in an automated way. cd ~/wc/subtree svn diff /tmp/subtree-changes.diff cd ~ svn co $URL/subtree other_wc svn patch /tmp/subtree-changes.diff other_wc This works fine even for new directories, deleted ones, etc. Caveat: It cannot do copies yet -- those will show up as simple adds. So moves and renames will lose their history? Yes. This is because the patch format cannot represent copies and moves. But how often do you split out a subtree that has copied or moved items within it? Can't you commit such changes from the existing working copy subtree before splitting it off?
Re: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 03:04:02PM +0200, Markus Schaber wrote: My most common (ab-)usage is to use this as a poor man's local branch feature. I'm working on some long-term task (e. G. some large refactoring or new feature), and get interrupted by some short fix which has to be developed on the fast lane. Often enough, my current working copy state is not stable enough (or does not even compile), or the fix touches the same files, but must be backportable independently, so I have to create that fix on a clean code base. Now, instead of checking out a new copy of the whole working environment (or copying the working copy, which needs a similarly long amount of time as we talk about about 2.5 Gigabytes in 58k files in about 38k folders), I just copy the one or two interesting subdirectories into a safe place, and locally revert all changes. After finishing and committing the intermediate fix, I delete the subdirectories, move my safe copies back into place, and then do svn update. So I'm not only detaching subdirectories, but also re-implanting them afterwards. Sounds like what you really need is this as-of-yet not implemented feature: http://subversion.tigris.org/issues/show_bug.cgi?id=3625 With svn 1.7, this would require at least one additional step (downgrade the working copy to the previous revision before the re-implant) and completely lose history for copies and renames. And especially those larger tasks are those which tend to contain copies and renames more often, as well as they have a higher likelihood to collide with fast-lane fixes simply due to the fact that they need a longer time. For the time being, I'd suggest to either keep a separate working copy around that can be used for quick fix work, or use the workarounds described in the issue I linked above (temporary branch, or 'svn patch'). If you don't have any copies or renames in your local changeset 'svn patch' works very well and fast for this use case.
Re: copying subdirectories in subversion 1.7
Markus Schaber wrote on Mon, Jul 25, 2011 at 15:57:00 +0200: Hi, Stefan, Von: Stefan Sperling [mailto:s...@elego.de] So I'm not only detaching subdirectories, but also re-implanting them afterwards. Sounds like what you really need is this as-of-yet not implemented feature: http://subversion.tigris.org/issues/show_bug.cgi?id=3625 Yes, that one would definitely help. :-) Maybe extending svn diff and svn patch to preserve copy/rename/history information would already be half of that implementation? A shelve subdir under .svn/ could then be used to store the diff files. That's one solution. However, wc.db already has the ability to represent multiple related trees (via op_depth), so another way would be to extend that into storing not only the post-'svn patch' trees too, and then merging them in the usual way. (which may require repository communication, or storing the pre-patch tree locally too...) Perhaps you'd be interested in contributing to the implementation of this feature? Best regards Markus Schaber
Re: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 12:17 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Markus Schaber wrote on Mon, Jul 25, 2011 at 15:57:00 +0200: Hi, Stefan, Von: Stefan Sperling [mailto:s...@elego.de] So I'm not only detaching subdirectories, but also re-implanting them afterwards. Sounds like what you really need is this as-of-yet not implemented feature: http://subversion.tigris.org/issues/show_bug.cgi?id=3625 Yes, that one would definitely help. :-) Maybe extending svn diff and svn patch to preserve copy/rename/history information would already be half of that implementation? A shelve subdir under .svn/ could then be used to store the diff files. That's one solution. However, wc.db already has the ability to represent multiple related trees (via op_depth), so another way would be to extend that into storing not only the post-'svn patch' trees too, and then merging them in the usual way. (which may require repository communication, or storing the pre-patch tree locally too...) Perhaps you'd be interested in contributing to the implementation of this feature? Because it interests me, I implemented a simple 'detach' script, which you can find here: http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py It's very hacky, and I do, of course, disclaim any harm which may come to your data which may come as a result of using this script. I am interested in any bug reports, however. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 4:14 PM, Hyrum K Wright hyrum.wri...@wandisco.comwrote: Because it interests me, I implemented a simple 'detach' script, which you can find here: http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py It's very hacky, and I do, of course, disclaim any harm which may come to your data which may come as a result of using this script. I am interested in any bug reports, however. Thanks Hyrum. It worked great for me on OSX. Only request might be some kind of output while it is running. Maybe some kind of message as it processes each folder. The command copies a subdirectory and its children from one WC to a new location to create a new WC. This is exactly how I think it should work as I can always go back to the original WC and run --set-depth=exclude if I wanted to remove the content from the source WC. I wonder if people will expect a script named detach to copy or do they think it will move? -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: copying subdirectories in subversion 1.7
I wonder if people will expect a script named detach to copy or do they think it will move? More like extract or promote -- promoting a child folder to become a full-fledged, independent working copy... liberate? Kinda like that... :-) -Message Disclaimer- This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email to conn...@principal.com and delete or destroy all copies of the original message and attachments thereto. Email sent to or from the Principal Financial Group or any of its member companies may be retained as required by law or regulation. Nothing in this message is intended to constitute an Electronic signature for purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic Signatures in Global and National Commerce Act (E-Sign) unless a specific statement to the contrary is included in this message. While this communication may be used to promote or market a transaction or an idea that is discussed in the publication, it is intended to provide general information about the subject matter covered and is provided with the understanding that The Principal is not rendering legal, accounting, or tax advice. It is not a marketed opinion and may not be used to avoid penalties under the Internal Revenue Code. You should consult with appropriate counsel or other advisors on all matters pertaining to legal, tax, or accounting obligations and requirements.
Re: copying subdirectories in subversion 1.7
Ryan Brothers wrote on Sun, Jul 24, 2011 at 17:42:43 -0400: Is there a way to create a new top-level checkout of a subdirectory with the 1.7 working copy format? Just copying a dir isn't supported. (the plan has been to provide a new subcommand for that, but that won't happen before 1.8) You might be able to duplicate the whole wc and do 'svn switch' to the subdirectory's URL (which will tell you to pass --ignore-ancestry), but I'm not sure how much server communication will be done in that case. (it will certainly contact the server, since without '-r' switch always assumes '-r HEAD')
Re: copying subdirectories in subversion 1.7
On Jul 24, 2011, at 16:57, Daniel Shahaf wrote: Ryan Brothers wrote on Sun, Jul 24, 2011 at 17:42:43 -0400: Is there a way to create a new top-level checkout of a subdirectory with the 1.7 working copy format? Just copying a dir isn't supported. It worked fine in 1.6.x and earlier. I too frequently use this. (the plan has been to provide a new subcommand for that, but that won't happen before 1.8) So 1.7 will be released with this regression in functionality?
Re: copying subdirectories in subversion 1.7
On Sun, Jul 24, 2011 at 05:08:14PM -0500, Ryan Schmidt wrote: On Jul 24, 2011, at 16:57, Daniel Shahaf wrote: Ryan Brothers wrote on Sun, Jul 24, 2011 at 17:42:43 -0400: Is there a way to create a new top-level checkout of a subdirectory with the 1.7 working copy format? Just copying a dir isn't supported. It worked fine in 1.6.x and earlier. I too frequently use this. (the plan has been to provide a new subcommand for that, but that won't happen before 1.8) So 1.7 will be released with this regression in functionality? It's not a regression because this feature was never officially documented or advertised. It just happened to work because of the way the old working copy was designed. That said, we knew people were doing this, and that shipping 1.7 without a new 'svn detach' subcommand might impact some users who relied on this. However, since the obvious workaround of getting a new checkout exists development resources went into more important stuff. So, sorry, you'll have to get a new checkout until 'svn detach' has been implemented. See http://subversion.tigris.org/issues/show_bug.cgi?id=2884 You can also keep using 1.6.x for the time being if detaching subdirectories is very important to you. 1.6.x is still going to supported until 1.8.0 is released.
Re: copying subdirectories in subversion 1.7
CC += dev@ Ryan Schmidt wrote on Sun, Jul 24, 2011 at 17:08:14 -0500: On Jul 24, 2011, at 16:57, Daniel Shahaf wrote: Ryan Brothers wrote on Sun, Jul 24, 2011 at 17:42:43 -0400: Is there a way to create a new top-level checkout of a subdirectory with the 1.7 working copy format? Just copying a dir isn't supported. It worked fine in 1.6.x and earlier. I too frequently use this. (the plan has been to provide a new subcommand for that, but that won't happen before 1.8) So 1.7 will be released with this regression in functionality? Yes. The 1.7 working copy format was designed to allow sharing pristines even between working copies, and this might happen in the 1.8 timeframe; but in 1.7 the answer is simply No[1].
