RE: Replacing branch contents with another branch
From: Graham Bartlett <ratelect_at_hotmail.com>
Date: Thu, 7 Aug 2008 10:03:52 +0000
Thanks for the replies, guys.
I guess I wasn't clear what I meant about "losing version history". Clearly the history for the previous branch will still be around, as will the history for the new branch. But how to find what changed from one to the next - that'd be the trick when you've deleted the previous branch. :-/
I should probably also mention that I'm using TortoiseSVN, as is the rest of the company here. If something needs doing which involves dropping back to the shell, that's not an option on a company-wid ebasis - it's got to be accessible from the Tortoise menus or from the repo-browser.
Mark says that doing the delete and branch from the repo-browser will only pull down differences from the server when I switch and update on my working copy. That sounds like a good move, although it's still a bit of a performance having four steps for this simple operation. And the issue of not being able to see what changed at this step (or being very hard to, anyway) is a bit of a drawback.
Likewise, Andrew's idea of rolling right back to the original branched copies and then remerging sounds feasible. This is going to be more intensive on server operations though - it needs to pull down the original and then pull down the new copy, where at least Mark's delete/branch/switch/update procedure will only get new versions for differences. On the plus side, Andrew's method makes it easier to track the changes on the rebranch. Since our trunk is fairly small, I'll probably end up using Andrew's workaround; if I'd been back at my last place though, Mark's more bandwidth-efficient solution would have been the way forward.
Mark, I'm afraid I disagree with you on whether a single operation to do this is necessary. Clearly I'm biased because I've raised the question! ;-) But I'll try to convince you (and others) why.
First off, this is a *very* common operation which all coders *will* need to do on a regular basis if they're using personal branches for development, or if they're using a "team" branch for a small group to work collaboratively towards a particular fix/feature which can be rolled into trunk. Maybe other list members have never needed to do this, but it's certainly been used regularly at every place I've worked for the last 15 years (everywhere which grokked branches anyway). And it's a feature which most other major version control systems I've used (VSS, ClearCase, Perforce) let you do. I'm not sure whether CVS lets you do this, because I've not used CVS to that kind of depth, but CVS isn't really an enterprise-level version control system anyway.
Second off, we should also consider the difficulty in carrying this out, or in figuring out how to do it. Mark, I presume you've got extensive SVN experience. When your average software engineer (like me) hits this problem for the first time, are they going to figure out this four-stage delete/branch/switch/update procedure? I think we can safely give that a big "Hell, no!" :-) Is it anywhere in the docs - use-cases perhaps? "Hell, no!" again - and in fact, the docs suggest that SVN by design *won't* let you do this. If this simple everyday operation requires an SVN expert to figure out how to do it, and the SVN expert says that this can only be achieved using a number of separate operations, and only then by working from the repo-browser rather than from "regular" Tortoise, then I think you've proved my point more completely than I could ever have done!
If the SVN team don't want to do this, it could be sorted in the Tortoise UI, of course. Provided there *is* a method for doing this in SVN, one menu selection in Tortoise could easily issue the multiple SVN commands required to carry it out. Personally I've got no problems with that, because I only use Tortoise. However I do think that people using SVN on the command line might also like this feature, so the most logical way would seem to be to add it to SVN.
Cheers,
Graham.
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.