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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-08 05:18:15 CEST