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

RE: RFC: Standardizing a 'svn:branch' (boolean) property

From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 16 Jul 2012 16:09:12 +0200

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: maandag 16 juli 2012 15:42
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
> On Mon, Jul 16, 2012 at 02:11:10PM +0200, Bert Huijben wrote:
> > Open questions:
> > * 'svn:branch' or maybe 'svn:root'?
> I'd prefer svn:branch but I don't care strongly.
> > * Which UI do/should we provide in 'svn'
> > svn cp --branch <PATH-OR-URL> URL
> > Performs a copy and makes sure there is a svn:branch property on the
> target
> >
> > svn mkdir --branch <PATH-OR-URL>
> > Creates a new branch
> I would favour a new 'svn branch' subcommand which is equivalent
> to 'svn copy' including a prop-add of 'svn:branch' at the copy target.

My initial version of this RFC had 'svn branch', but then I was thinking
that we might only learn which features we want for that command later.

svn switch --relocate had a similar history. It was a quick and dirty search
and replace of a url prefix, which is much cleaner implemented as 'svn
relocate' since 1.7 with a slightly different behavior.

But, It would be nicer if we can get it properly defined now :-)

> > * How should we handle 'svn:branch' on multiple levels. E.g. on ^/trunk
> and
> > ^/trunk/projects/my?
> > [I don't see a problem with just allowing it as long as we usually only
> > up to find the first ancestor]
> I would say that first svn:branch prop we find while traversing
> upwards wins. This would allow people to branch and merge within
> subtrees as they can do today.

That was my reasoning,

Received on 2012-07-16 16:09:54 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.