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

RE: Feature Req: sorthand urls for branches/tags in CLI

From: Andrew Reedick <Andrew.Reedick_at_cbeyond.net>
Date: Fri, 23 Aug 2013 10:06:37 -0400

> -----Original Message-----
> From: Laszlo Kishalmi [mailto:lkishalmi_at_ovi.com]
> Sent: Thursday, August 22, 2013 5:15 PM
> To: users_at_subversion.apache.org
> Subject: Feature Req: sorthand urls for branches/tags in CLI
> Implementation ideas:
> We put a specific property on project1 folder let's call it
> svn:branches for now. Here we could describe the layout of
> branches and tags for that part of repository. E.g.:
> a) Using prefixes:
> /
> /branches/
> /tags/
> b) Using some custom mapping/lists:
> trunk
> branches/*
> tags/*
> c) Using regexp captures:
> (trunk)
> branches/(\w+)
> tags/(\w+)
> Having this info, the path where this property is set, the name
> of the branch and the current path relative to wc root it is
> possible to construct a repository URL to be used.
> As far as I currently see there would be no change required on server
> side.

Subversion doesn't have branches. I'd rather see branches as first class objects before we hack out a "-b" option. It's still an interesting idea, though.

What happens when the svn:branches property gets merged or copied? It's an edge case, but it could cause an amusing amount of chaos if svn:branches gets copied around or merged unexpectedly.
What is the behavior when you are in an externals? Do you respect the svn:branches in the externals, or do you work from the local repo's svn:branches, or neither?

Overall, I'm not sure it would save a significant amount of typing. If you have a standard trunk/branches/tags repo structure, then you're not saving a lot by using "-b foo" in place of "^/branches/foo". Having to set 'svn:branches' for repos with non-standard trunk/branches/tags trees is a bit inconvenient and would discourage use.
Received on 2013-08-23 16:08:16 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.