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: Subversion: existing users
On 07/24/2011 03:25 AM, Ryan Schmidt wrote: On Jul 23, 2011, at 03:27, Andy Canfield wrote: On 07/21/2011 07:27 PM, Cooke, Mark wrote: I don't use *nix much but shouldn't that be `chown -R ...`? Nope, the format of that command on Linux is chown username.groupname fileselector Generally chown has to be run as root in order to be allowed to change the file owner. The command on OS X is nearly the same but the user and group are separated by a colon, not a period. -R means recursive, and yes, you probably did want to have used that option so that all items in the directory, and not just the directory itself, have their ownership corrected. You're right; -R means recursive. I have never used 'chown -R'. In this case I did not need it because I applied the chown immediately after creating the SVNParent. Here is the latest version: *APACHE_USER=www-data APACHE_GROUP=www.data SVNPARENT=/data/svn sudo mkdir $SVNPARENT **sudo **chown $APACHE_USER $SVNPARENT **sudo **chgrp $APACHE_GROUP $SVNPARENT sudo chmod 0700 $SVNPARENT *
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?
Source code lines transposed on checkout
I have on two occasions had two lines of code transposed on an SVN Tortoise checkout. In both cases the code was VB6. In each case an Exit command was transposed with an End If line. The code below provides an example. ' Case 1: End if Swapped with Exit For For ... If ... Then ... Exit For End If Next ' Case 2: End if Swapped with Exit Property If ... Then ... End If Exit Property On checkout to one computer the code was transposed as: ' Case 1: End if Swapped with Exit For For ... If ... Then ... End If Exit For Next ' Case 2: End if Swapped with Exit Property If ... Then ... Exit Property End If Additional detail: In each case I checked the same baseline out on a second computer and the lines were not swapped. I reversed the lines to correct for the error, and did a DIFF, which showed the line order correct. I checked in and did a DIFF between the current code and the original revision, no differences were found. We have not been able to repeat this problem. But since the issue involves End If with Exit commands, different baselines, different users, and different SVN repositories, I'm at a loss on where to look next. Jeff Abbott Systems Architect CAE Professional Services 2603 discovery drive, Orlando, fl 32826 Orlando, FL 32817 jeff.abb...@caemilusa.commailto:jeff.abb...@caemilusa.com Work: 407-745-2605 Cell: 407-222-7909 We are often better served by connecting ideas than we are by protecting them. -Steven Johnson, Where Good Ideas Come From: The Natural History of Innovation ***This e-mail message is intended only for the above named recipient(s) and may contain information that is sensitive or proprietary. If you have received this message in error or are not the named recipient(s), please immediately notify the sender, delete this e-mail message without making a copy and do not disclose or relay this e-mail message to anyone.***
AW: copying subdirectories in subversion 1.7
Hi, Von: Stefan Sperling [mailto:s...@elego.de] 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? 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. 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. Best Regards, Markus Schaber
Re: AW: copying subdirectories in subversion 1.7
On 7/25/11 7:49 AM, Markus Schaber wrote: Von: Les Mikesell [mailto:lesmikes...@gmail.com] 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? My guess is that this Design was inherited from CVS. And AFAICS, the initial set of developers had some common members with the CVS developers, and it changed gradually, there was no revolution replacing all existing developers with new ones. The tradeoffs are sort of obvious, but it seems like a very drastic change to make with no option to maintain the old behavior. -- Les Mikesell lesmikes...@gmail.com
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.
AW: copying subdirectories in subversion 1.7
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. Best regards Markus Schaber
Re: AW: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 9:08 AM, Les Mikesell lesmikes...@gmail.com wrote: On 7/25/11 7:49 AM, Markus Schaber wrote: Von: Les Mikesell [mailto:lesmikes...@gmail.com] 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? My guess is that this Design was inherited from CVS. And AFAICS, the initial set of developers had some common members with the CVS developers, and it changed gradually, there was no revolution replacing all existing developers with new ones. The tradeoffs are sort of obvious, but it seems like a very drastic change to make with no option to maintain the old behavior. In SVN 1.6 and earlier it is not like someone wrote code specifically to allow people to copy/move folders out of their WC. It was just something that fell out of the design. There are plenty of instances where people did not want this behavior, and for them it is now fixed. For example, in Eclipse this has always been a huge problem. Users would copy and paste a folder and this would silently bring the .svn folder with it which was not what was desired. I mention Eclipse simply because this is one of the only events where it does not provide a hook for plugins to get involved so the SVN plugins for Eclipse are not able to detect and fix this situation and it is perceived as a bug. The opinion was that if users really want to be able to easily detach folders from their working copy someone will step up with scripts and/or patches to add a feature to SVN to do it. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: AW: copying subdirectories in subversion 1.7
On 7/25/2011 9:24 AM, Mark Phippard wrote: Von: Les Mikesell [mailto:lesmikes...@gmail.com mailto:lesmikes...@gmail.com] 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? My guess is that this Design was inherited from CVS. And AFAICS, the initial set of developers had some common members with the CVS developers, and it changed gradually, there was no revolution replacing all existing developers with new ones. The tradeoffs are sort of obvious, but it seems like a very drastic change to make with no option to maintain the old behavior. In SVN 1.6 and earlier it is not like someone wrote code specifically to allow people to copy/move folders out of their WC. It was just something that fell out of the design. Agreed, but it is a logical design that falls out of the way subdirectories work and the way people use them. There are plenty of instances where people did not want this behavior, and for them it is now fixed. Agreed again. Although the change I would have preferred would have been an option to not keep a pristine copy at all for the circumstances where it doesn't work out well. For example, in Eclipse this has always been a huge problem. Users would copy and paste a folder and this would silently bring the .svn folder with it which was not what was desired. I mention Eclipse simply because this is one of the only events where it does not provide a hook for plugins to get involved so the SVN plugins for Eclipse are not able to detect and fix this situation and it is perceived as a bug. The opinion was that if users really want to be able to easily detach folders from their working copy someone will step up with scripts and/or patches to add a feature to SVN to do it. I'm not arguing that the change is bad or shouldn't have been done, just that it is a very surprising change in design philosophy, and projects that make surprising design changes without concern for existing use patterns make me nervous about what other surprises may be lurking in them. -- Les Mikesell lesmikes...@gmail.com
Re: AW: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 09:49:13AM -0500, Les Mikesell wrote: I'm not arguing that the change is bad or shouldn't have been done, just that it is a very surprising change in design philosophy, and projects that make surprising design changes without concern for existing use patterns And the fact that we carefully considered this case, discussed it, and came to a conclusion, does not comfort you? That we documented known workarounds for this uses case even though it has never been officially supported? It's not like we are being secretive about it or didn't care about users who use this feature. make me nervous about what other surprises may be lurking in them. Any other surprises we know about are documented in the release notes. If there are additional ones we don't know about them and they will hopefully be found during beta testing. If you find one, let us know :)
Re: AW: copying subdirectories in subversion 1.7
On Mon, Jul 25, 2011 at 10:13:43AM -0500, Les Mikesell wrote: On 7/25/2011 9:58 AM, Mark Phippard wrote: You agree but you are also missing or glossing over my point. When you copied that subdirectory you were not using a feature of SVN, you used the OS. SVN cannot provide an option on the OS copy command. And you seem to have missed the point that people understand and use OS level commands and expect them to work. I'm sure I didn't invent the idea of doing that, so it has almost certainly been promoted as an advantage of the design on this list and in usage tutorials if not in official documentation. As I've already mentioned, to the best of my knowledge, copying subdirs to create new working copies was never recommended in official documentation. Given how closely you follow the project, I am surprised you are surprised. I'm not surprised that the capability is not there in the new/different WC format. I'm surprised that there is no option to maintain currently-expected behavior in a release version. It is wrong to expect it. It doesn't even work properly in 1.6 in some cases (you cannot copy a locally added tree without its parent and expect it to work as an independent working copy -- not that such an operation would make sense). This release has taken over 2 years and the new WC design has not changed from the original proposal. If you go back to the lists you will see the ramifications of this change were being discussed even while we were still working on SVN 1.6 and the need for an svn detach was raised back then. Which makes it even more surprising that it was omitted. You cannot omit something which doesn't exist yet. The 'svn detach' subcommand has not been added because there was no time left to implement it in the 1.7.x release cycle. There are enough improvements in 1.7.x that make the upgrade worthwhile regardless.
Re: AW: copying subdirectories in subversion 1.7
I think you've made your point by now. However, 1.7 is close enough to being released that this feature will NOT be included in it. How do you suggest to proceed? Personally, I'd suggest documenting this in the 1.7 release notes and contributing the hands to work on this for 1.8. Les Mikesell wrote on Mon, Jul 25, 2011 at 10:13:43 -0500: I'm surprised
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
configure subversion for no history
Is there a way to configure Subversion to *not* store a history on certain files? I have a few people checking in some large binaries and we really don't need to store history on them. We only need the last committed version of the file. The repository is growing unnecessarily large. Kent
Re: configure subversion for no history
On Mon, Jul 25, 2011 at 1:29 PM, Kent Rollins kent.roll...@gmail.com wrote: Is there a way to configure Subversion to *not* store a history on certain files? I have a few people checking in some large binaries and we really don't need to store history on them. We only need the last committed version of the file. The repository is growing unnecessarily large. The short answer from my experience is no. Eliminating the old histories, or even expired tags that might have such binaries, is not supported. Histories are considered quite important, and efforts to discard them or even to eliminate inappropriately stored binaries or private data have proven to be very awkward. (Look up the old svn obliterate feature requests for some history on that.) A better approach to this might be to use svn:externals to point to a separate repository, or set of repositories, which can be updated and discarded as necessary.
svn update via HTTPS works 95% of the time, then randomly shanks, issuer not trusted
Greetings, I'm at my wit's end trying to debug a troubling, highly irregular issue connecting to a SVN server via HTTPS. I am very confident this is a client issue, not a server issue. The server is CollabNet's Subversion Edge server, which has 1.6.15 built in. The client is 1.6.15 running under Cygwin. I have many, many clients, most of which are running Windows Server 2003 (if that matters)--all Cygwin, all this same package. Lots of traffic every day. Almost all of it works just fine. Now, a very important fact: the svn operations WORK 95% of the time. They just work. Everything is absolutely fine. This is an unattended, fully-automated environment, launched from cron (well, Task Scheduler when running on these Windows boxes). 95% of the time, the job launches, runs my svn update command from within one of its working copies: svn update --username=some --password=thing --non-interactive and it works beautifully. Every once in awhile, for absolutely no reason I can find (have looked at logs, logs, logs, timing, the stars and planets, everything), with absolutely nothing that I can find having changed, it dies with this: svn: OPTIONS of 'https://myserver:/svn/some/path': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://myserver:) (I have changed the paths/ports to protect the innocent). Now for most of my clients, the issued for a different hostname part is omitted--they still have the issuer not trusted part. That's because my one host that I'm really digging in to debug this has to use a different hostname for certain reasons. So, focus on the issuer not trusted part because that's what we see across all clients. But keep in mind: it works. It works 95% of the time. I change absolutely nothing. Having found no indication of why it will *randomly* fail with the above error, I decided to add the --trust-cerver-cert flag, thinking surely this will eliminate all woes. Just trust it and go (trust it like you already do 95% of the time anyway)! svn update --username=some --password=thing --non-interactive --trust-server-cert But, nope, I randomly get the very same error. These key facts: 1) It works 95% of the time (well, maybe 85%) 2) I can find NOTHING changing (on client or server) between a working op and a breaking op--it's all automated, and just randomly shanks are leading me to believe that this error message is actually a complete wild goose chase, and that the problem is not actually cert-based but is something else (with a wrong error message). In looking at the server HTTP logs, it does indeed appear that the client bails out before continuing the connection--there's no log, meaning it does appear that the client can't handshake (or refuses to), and then quits. I have thought about adding options to config (on the command line) such as ssl-trust-default-ca, but again, I already told svn to --trust-server-cert and it randomly still dies, so I don't think that will help. You'll be tempted to focus on SSL cert issues on the server or something, but remember that we don't change anything and it works fine almost all the time! (I'm still open to any thoughts of course). Can anybody point me to some other debug options, some other flag, or any other way to determine why, 15% of the time, it dies, yet 85% of the time it updates just fine? Thanks, Dan
Decompression of svndiff data failed - Unpacking a repository
Hello, We've recently installed Fisheye to index our Subversion repository. However, it kept looking over an error on SVN. Trying to reproduce the error, I effectively received an error message when performing a diff between two version. svn diff -r 233984:233985 file:///opt/subversion/repository/filename@233985 svn: Decompression of svndiff data failed So far, all my search pointed to a corruption performed by mod_dav_svn and the only solution has been to run a script called fsfsverify.py I cloned my repository, downloaded this script and ran it, only to find out it won't support packed shard. I need to know if there's a way to unpack a single shard so that I can run this script on the faulty revision and repair it, without having to either unpack the whole repository or do a dump / load. Thanks -- *Philippe Busque* , rue St-Charles Ouest, Tour Est, bureau 255 Longueuil (Québec) Canada J4K 5G4 Tél. : 450-449-0102 ext. 3017 Télec. : 450-449-8725 Ce message et les fichiers d'accompagnement transmis avec celui-ci s'adressent expressément au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez en aviser immédiatement l'expéditeur par courrier électronique. Veuillez également ne pas en prendre connaissance et en supprimer toutes les copies immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales n'acceptent aucune responsabilité à l'égard des opinions exprimées dans le message ou des conséquences de tout virus informatique qui pourrait être transmis avec ce message. Ce message fait également l'objet d'un copyright. Il est interdit d'en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement écrit du détenteur du copyright.
Re: configure subversion for no history
On Jul 25, 2011, at 12:29, Kent Rollins wrote: Is there a way to configure Subversion to *not* store a history on certain files? Definitely not. Storing history is the primary purpose of Subversion. If you don't want history, Subversion may not be the right tool for you.
Re: Decompression of svndiff data failed - Unpacking a repository
Philippe Busque wrote on Mon, Jul 25, 2011 at 15:05:29 -0400: I need to know if there's a way to unpack a single shard so that I can run this script on the faulty revision and repair it, without having to either unpack the whole repository or do a dump / load. Thanks The shards are independent, and fsfsverify.py operates on one revision at a time. It should be possible to extract just one revision from the pack file (use its manifest file), fix it, and then sew the pack file back together (and also fix the manifest file if the fixed rev file has a different length). There is also a script in tools/, called fsfs-reshard.py, that may be useful.
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.
How to clean the working dir from .svn folders ?
Hi all, so my problem is clear : I've a working dir and I want to clean it up from all .svn folders, how to ? Knowing that I'm working un CLI within exec() function of PHP. Unfortunately I can't delete manually files and folders : Warning: unlink(svn/.svn/all-wcprops) [function.unlink]: Permission denied in C:\wamp\www\lang_editor\include\functions.inc.php on line 325 And the 'export' function is not what I want because my aim is to delete the folder, not really get a clean copy. If there is no way I think we must add a new function to SVN, such as 'svn unlink' or 'svn dissociate' Regards, Damien.
RE: How to clean the working dir from .svn folders ?
Hi all, so my problem is clear : I've a working dir and I want to clean it up from all .svn folders, how to ? Knowing that I'm working un CLI within exec() function of PHP. Unfortunately I can't delete manually files and folders : Warning: unlink(svn/.svn/all-wcprops) [function.unlink]: Permission denied in C:\wamp\www\lang_editor\include\functions.inc.php on line 325 And the 'export' function is not what I want because my aim is to delete the folder, not really get a clean copy. If there is no way I think we must add a new function to SVN, such as 'svn unlink' or 'svn dissociate' If you can run svn can you not run the shell rm command? BOb
