subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: Feature Req: sorthand urls for branches/tags in CLI
Date Fri, 23 Aug 2013 14:37:47 GMT
On 23.08.2013 16:06, Andrew Reedick wrote:
>> -----Original Message-----
>> From: Laszlo Kishalmi []
>> Sent: Thursday, August 22, 2013 5:15 PM
>> To:
>> 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
> 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.  

Actually I find the idea of having a single propery to define project
layout totally wrong. What if, at a later date, you change the project
structure? Who is responsible for updating the property? How do you keep
it in sync with reality? How do you detect that it's out of sync?

Those are just a few considerations that have to be addressed, and
frankly I don't think there's any sane way of addressing them. This is
like the svn:externals mess all over again.

It would be much safer IMO if the root of each branch were identified by
a property instead. For example: we could introduce an svn:branch
property that can be set only on directories. The presence of such a
property tells the client and server that the directory is a branch and
should be treated specially. The property could not be manipulated
directly via propset or propedit, but only through branch-specific
commands; for example:

  * svn mkdir --branch
    Creates a new directory with the svn:branch property set, with an
    empty value
    Example: svn mkdir --branch http://host/repo/trunk
  * svn copy
    If the source is a branch, the target also becomes a branch. The
    value of the target's svn:branch property is the path@revision of
    the source (thus, the client and server can easily recognize related
    branches and branch points). Using property inheritance, client and
    server can enforce constraints on allowed branching (e.g., forbid
    branching into a copy of the source branch)
  * svn move
    Can implement restrictions upon where branches can be moved to,
    similar to "svn copy"
  * svn diff, svn merge, svn switch
    These commands could make use of a (new) shorthand syntax to
    identify branches, based on their (base)name and the presence of the
    svn:branch property.

We actually had quite a fight^Winteresting discussion about this at the
Berlin hackathon this year.

-- Brane

Branko ─îibej | Director of Subversion
WANdisco // Non-Stop Data

View raw message