[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: Varnau, Steve (Seaquest R&D) <steve.varnau_at_hp.com>
Date: Fri, 10 May 2013 15:51:46 +0000


> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Friday, May 10, 2013 08:41
> To: Andrew Reedick
> Cc: Branko Čibej; users_at_subversion.apache.org
> Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams
> aka Branches as First Class Objects?
> On Fri, May 10, 2013 at 10:20:54AM -0500, Andrew Reedick wrote:
> > It makes me wonder if it would make sense to slap a higher-level
> > interface on top of svn in order to implement the process aspects of
> > version control (and otherwise hide/keep the lower level
> > details/quirks away from users.)
> Yes, that makes sense.
> Subversion doesn't know anything about process. It only cares about
> version control. Process aspects are left to higher-level tools.

With a toolset like Subversion, having a simple, elegant design is key for many benefits.
There is definitely a trade-off between exposing the user interface at that level (basic operations add, cp, mv) versus exposing higher level concepts (branches, tags).

Providing only the lower level stuff gives more flexibility for people to use it creatively and do things that might not be possible with higher-level, but more rigid concepts.

Unfortunately, that also leaves us with having to define the higher level stuff ourselves. I support a big team (on the order of 150 engineers). They don't all have time to be svn experts, but to be productive team we all have to follow common conventions. I really miss not having branches and tags be first order objects.

Subversion is more like a toolset and you have to build your own machine. (Or as we say, it's a box of rope. You can do a lot with rope, but sometimes you hang yourself.)

As a version control tool, branches and tags seem like something that ought to be there, instead of merely conventions. But how I'd like to see there semantics work might be very different than other peoples'. So flexibility is a good thing.


> For example, Subversion is often tied to an issue tracker, with a pre-
> commit hook that requires an issue number in the log message and then
> checks the status if the issue to decide whether the commit should be
> allowed according to policy.
> Or people use hook scripts such as this one:
> http://svn.haxx.se/dev/archive-2012-04/0392.shtml
> http://svn.haxx.se/dev/archive-2012-04/0394.shtml
> I've also seen custom Subversion clients written to support a particular
> process.
Received on 2013-05-10 17:53:10 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.