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

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

From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 16 Jul 2012 14:11:10 +0200


On the Berlin hackathon the suggestion was raised that it might help that we
standardize a new 'svn:branch' property to give tooling a hint on what
directories are branches and which aren't. To make sure we don't forget
about this idea I just drop this on the list with the information I have. I
hope others can extend this proposal with their own ideas.

Client tools like TortoiseSVN, Subclipse, AnkhSVN could really use some
standardized hint to suggest better defaults to the user.

* Merge and branch tools can automatically suggest which directory to merge
* Policy tools could use this to enforce policies with less
configuration/local rules. (Tags created must have the property; inside a
tag only certain kinds of changes are allowed)
* I don't think we can/should enforce a default policy in Subversion as that
breaks backword compatibility.

As we couldn't think of a usage of the content I would suggest that we just
always set the property to '*', just like how we handle svn:executable,
svn:needs-lock, etc. This would also make sure that merges of this property
won't need special handling.

When the inherited-properties branch will be merged to trunk it will be very
easy (and for working copies even a local operation) to determine in which
branch a path is.
Open questions:
* 'svn:branch' or maybe 'svn:root'?

* 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

* How should we handle 'svn:branch' on multiple levels. E.g. on ^/trunk and
[I don't see a problem with just allowing it as long as we usually only look
up to find the first ancestor]

Feel free to join the design discussion.

Received on 2012-07-16 14:11:59 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.