[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

From: Andrew Reedick <Andrew.Reedick_at_cbeyond.net>
Date: Tue, 21 May 2013 14:13:33 -0400

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: Tuesday, May 21, 2013 11:41 AM
> To: Bob Archer
> Cc: Zé; users_at_subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
>
>
> Of course you can 'list branches' as long as you follow and remember
> _your_ convention for where they are. You can also delete them to the
> extent that they don't show up in this list (even though they can still
> be accessed with peg revision syntax and the actions show in the
> log history of the parent directory). This is nicer in many ways
> than just having one special-case 'branch' namespace, especially when
> you have many projects in the same repository and/or you like to
> separate your release, QA, and experimental branches so different
> groups don't have to deal with the clutter from the others.
> Subversion doesn't force you to follow good conventions (and I think
> this thread started because someone didn't and the rename of a
> directory above where they put a branch was recorded as a change in
> both the branch and its parent), but you can if you want.
>

Right, right, it's the user's fault for failing to predict future "namespace" needs. That the repository was created when the project was small and that the user in question inherited the repo aren't valid excuses either.

Next time I'll implement top level directory changes via 'svnadmin dump/load' to avoid spurious log entries under branches/tags.

Translation: Les, that wasn't a very realistic or helpful piece of advice.
Received on 2013-05-21 20:14:53 CEST

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.