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

Re: Branch root identification -- a (really) simple proposal

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 9 Sep 2009 19:09:39 +0200

On Wed, Sep 09, 2009 at 11:46:56AM -0400, C. Michael Pilato wrote:
> I was thinking today about how Subversion offers all this flexibility in
> terms of branch creation ("it's just a copy of a directory!") but sometimes
> at the cost of some benefits you might otherwise get from a first-class
> branch object.
>
> Could a really, really simple solution help here? What if Subversion
> recognized a directory property (say, "svn:branch-root") as an indicator
> that that directory is the root of a branch (where by "branch", I mean "line
> of development", which includes trunk and tags)? Benefits could include:
>
> * the fact that the property would naturally get set on copies of that
> directory, ensuring that branches of the directory are annotated as
> such.
>
> * helping the client discourage commits of subsets of a branch.
>
> * helping the client warn users about merging at anything less than
> the branch level.
>
> * helping tools like ViewVC and Trac identify branches, and add UI
> goodness accordingly.

* creates mergeinfo on copies only if the copy crosses an svn:branch
  property (requiring users to set the property on existing repositories
  when upgrading to make use of this feature, else, you get no mergeinfo
  on copies at all).

> It sounds too simple to be truly useful. What do others think?

+1

I've proposed this before some time ago, for both branches and tags:
http://svn.haxx.se/users/archive-2009-02/0729.shtml
And again, just yesterday:
http://svn.haxx.se/users/archive-2009-09/0292.shtml

Stefan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2393009
Received on 2009-09-09 19:10:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.