You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Graham Bartlett <ra...@hotmail.com> on 2008/08/06 14:56:42 UTC
Replacing branch contents with another branch
Hi all,
This is a question I posted on SVNForum.org and didn't get a reply to. I wasn't very complimentary about SVN over there, which might be why - I can only say that I was having a bad day, and SVN woes weren't helping. Anyway, I'll try again and hopefully someone can either (a) explain how to do it, (b) second me in requesting a bugfix, or (c) give me a good reason why I wouldn't want to work this way. If (c), note that "Because SVN can't do it" is not a good reason. ;-)
OK, the situation...
We have a code trunk, into which all the latest development goes. I have a personal branch, branched from the code trunk at some earlier revision, in which I do my own work before submitting to trunk. The plain-vanilla textbook way of using branches, in other words.
During my hacking, my personal branch inevitably acquires a few bodges, workarounds and test point printf's for things I've done along the way. I've checked them in, because we all need access to these bodges while we're looking at what we're fixing. I don't want these hacks to go back into trunk, nor do I necessarily still want them in my branch. They're not a problem right now, but the work I needed them for has come and gone.
As time goes on and other people submit changes to trunk, my personal branch diverges further from trunk, until I decide I need to get my personal branch back to head of trunk. What I'd like to do now is say "merge from trunk to branch", select to merge from head of trunk to head of my branch, and say "replace everything". This would delete files from my personal branch which were deleted on trunk, add any new files created on trunk, and replace any common files with the versions in trunk. I don't want merged versions of files which use merge-tracking to combine changes on my personal branch and changes on trunk; I just want my personal branch to become a copy of trunk and blow away the obsolete hacks in my personal branch.
http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.wholebr says that simply comparing one branch tree to another branch tree is "wrong". In many cases it is, but in some cases it's "right" for the job the user's wanting to do. Whilst the merge-tracking feature is very nifty most of the time, sometimes (like this) the user just want a dumb overwrite. As far as I can see, SVN simply doesn't provide this ability. All variations of merging that I've tried have resulted in merge-tracking trying to combine changes on my personal branch with changes on trunk to create a third Frankenstein's-Monster offspring of the two, or alternatively with no changes to the branch at all. (And yes, that was *every* permutation of merge options available in TortoiseCVS - it took me the better part of an afternoon to test them all!)
A workaround is that I delete my entire working branch, commit that, and then rebranch from trunk - possibly using the same name for the working branch, or possibly using a different branch name. That gets me working, but it's a very nasty hack. The most significant problem is that I lose version history from my pre-merged personal branch to my post-merged personal branch, so if I want to check what changed when I pulled down the latest version, that is not possible. A less significant problem but still a deal-killer on many systems is the simple mechanics of doing the delete, commit and rebranch. At my last company, the full tree was about 3GB, so a delete, commit and rebranch would keep your machine tied up for a very long time indeed. On a tree this size, the majority of the files clearly *won't* have changed, so a merge which just took the head-of-trunk versions of all changed files would turn a "forget-about-this-machine-for-the-rest-of-the-day" job into a "2-minutes-anytime-you-like" job.
Does anyone have any good ideas on this one? As far as I can see, I'm not trying to do anything earth-shatteringly different here, so I'm very surprised that this isn't playing ball. Apologies for the lengthy description, but I'd rather give full information at the start, instead of giving people incomplete info and then trying to fill in the gaps later.
Cheers,
Graham.
_________________________________________________________________
Win New York holidays with Kellogg’s & Live Search
http://clk.atdmt.com/UKM/go/107571440/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Replacing branch contents with another branch
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 7, 2008, at 05:03, Graham Bartlett wrote:
> 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. :-/
Then don't delete the previous branch. Keep it around under a
different name, e.g. with the date when it was created (or deleted).
> 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.
Of course the members of this list cannot control what features
TortoiseSVN does or does not offer.
> 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.
There is a way to issue multiple commands in a single statement and
get them committed to the repository all at once, from the command
line. It's called svnmucc.
I don't see why deleting a trunk and replacing it with a branch is a
very common operation for you, especially since you're calling them
team branches or personal branches. Is it really the case that nobody
else is working on the trunk during this time? Or on a different
personal or team branch? If that is really the case, then why bother
to create a branch at all? Just work on the trunk. But if branching
is necessary, and multiple different groups are working on multiple
different branches, then you want to be able to merge the changes
from those branches into the trunk when they're done. And you don't
want to discard those changes which have been made on trunk in the
mean time. Subversion handles this through merging. There's a whole
chapter about it in the book.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Replacing branch contents with another branch
Posted by Graham Bartlett <ra...@hotmail.com>.
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.
_________________________________________________________________
Win New York holidays with Kellogg’s & Live Search
http://clk.atdmt.com/UKM/go/107571440/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Replacing branch contents with another branch
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Graham Bartlett [mailto:ratelect@hotmail.com]
> Sent: Wednesday, August 06, 2008 10:57 AM
> To: users@subversion.tigris.org
> Subject: Replacing branch contents with another branch
>
>
> A workaround is that I delete my entire working branch, commit that,
> and then rebranch from trunk - possibly using the same name for the
> working branch, or possibly using a different branch name. That gets
> me working, but it's a very nasty hack. The most significant problem
> is that I lose version history from my pre-merged personal branch to
my
> post-merged personal branch, so if I want to check what changed when I
> pulled down the latest version, that is not possible.
Another possible solution might be to unmerge (reverse merge)
your code changes to get back to the original copy of trunk and then
merge from trunk. In theory, you keep all your merge history on one
branch and otherwise don't have to deal with peg revisions/branches.
> The most significant problem
> is that I lose version history from my pre-merged personal branch to
my
> post-merged personal branch, so if I want to check what changed when I
> pulled down the latest version, that is not possible.
Not true. The information is there, but it's a pain to get the
information since you have to remember/find all the peg branches and
query on each branch for merge information. (This is for 1.4, no idea
if 1.5 makes it easy to get merge info from peg branches or not.) On a
side note, does svnmerge.py handle peg branches?
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Replacing branch contents with another branch
Posted by Murli Varadachari <mv...@facebook.com>.
In svn 1.5 the ³svn merge accept theirs xxxxx² command is useful to
specify that during conflicts the ³from² sources should be selected [ in
this example the ³trunk² ].
Potentially this option could be expanded to with an additional ³-all² so
that all files can be pulled in from the trunk without merges etc just a
thought.
IMHO the ability to full replace a branch with a completely new version of
trunk will be useful !
Cheers
murli
On 8/6/08 9:32 AM, "Mark Phippard" <ma...@gmail.com> wrote:
> On Wed, Aug 6, 2008 at 10:56 AM, Graham Bartlett <ra...@hotmail.com> wrote:
>
>> > A workaround is that I delete my entire working branch, commit that, and
>> then rebranch from trunk - possibly using
>> > the same name for the working branch, or possibly using a different branch
>> name. That gets me working, but it's a
>> > very nasty hack. The most significant problem is that I lose version
>> history from my pre-merged personal branch to
>> > my post-merged personal branch, so if I want to check what changed when I
>> pulled down the latest version, that is
>> > not possible. A less significant problem but still a deal-killer on many
>> systems is the simple mechanics of doing the
>> > delete, commit and rebranch. At my last company, the full tree was about
>> 3GB, so a delete, commit and rebranch
>> > would keep your machine tied up for a very long time indeed. On a tree
>> this size, the majority of the files clearly
>> > *won't* have changed, so a merge which just took the head-of-trunk versions
>> of all changed files would turn a
>> > "forget-about-this-machine-for-the-rest-of-the-day" job into a
>> "2-minutes-anytime-you-like" job.
>
> You can do all this via URL and the update/switch of your working copy
> is only going to pull the net changes. So there is no reason you need
> to tie up your machine.
>
> I'd say SVN already can do what you want and you do it the way you
> suggested. I do not think this justifies some new command, and even
> if one was created it would just do the delete + re-branch internally
> anyway so nothing would behave differently.
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Replacing branch contents with another branch
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Aug 6, 2008 at 10:56 AM, Graham Bartlett <ra...@hotmail.com> wrote:
> A workaround is that I delete my entire working branch, commit that, and then rebranch from trunk - possibly using
> the same name for the working branch, or possibly using a different branch name. That gets me working, but it's a
> very nasty hack. The most significant problem is that I lose version history from my pre-merged personal branch to
> my post-merged personal branch, so if I want to check what changed when I pulled down the latest version, that is
> not possible. A less significant problem but still a deal-killer on many systems is the simple mechanics of doing the
> delete, commit and rebranch. At my last company, the full tree was about 3GB, so a delete, commit and rebranch
> would keep your machine tied up for a very long time indeed. On a tree this size, the majority of the files clearly
> *won't* have changed, so a merge which just took the head-of-trunk versions of all changed files would turn a
> "forget-about-this-machine-for-the-rest-of-the-day" job into a "2-minutes-anytime-you-like" job.
You can do all this via URL and the update/switch of your working copy
is only going to pull the net changes. So there is no reason you need
to tie up your machine.
I'd say SVN already can do what you want and you do it the way you
suggested. I do not think this justifies some new command, and even
if one was created it would just do the delete + re-branch internally
anyway so nothing would behave differently.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org