[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: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 23 Aug 2013 16:37:47 +0200

On 23.08.2013 16:06, Andrew Reedick wrote:
>
>> -----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.

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_at_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
e. brane_at_wandisco.com
Received on 2013-08-23 16:38:23 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.