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

Re: Special support for tags and branches

From: <hakon_at_ion.no>
Date: 2006-07-12 19:32:04 CEST

>> How do you Martin, as a Subcommander developer, view my suggestion that
>> Subversion should standardize on using properties to locate the tags-
>> and
>> branches- directories, and to use properties to mark a tag (in the tags
>> directory) and a branch (in the branch) directory?
> I don't know. Thinking more about it, subversions copy tags offer a lot
> of flexibility and it is not so easy to provide a "simple" interface.
> Another example. At work we have a layout that looks something like this:
> /tags
> /2.10.1
> /2.10.2
> /2.10.3
> /branches
> /2.10.x
> /trunk
> /vendor
> /xercesc
> /current "trunk"
> /2.6.0 "tag"
> /2.6.1 "tag"
> The trunk/branches/tags is the standard layout. Branches are made by
> copying
> /trunk to /branches/<name> and tags are made by copying /trunk or
> /branches/<name> to /tags/<name>.
> Now the interesting part is the vendor branch. The /current path is
> similar
> to /trunk for the vendor library. New versions are checked in on the
> /current
> path. But the tag for the new version is not placed in the /tags path but
> alongside the /current path (the 2.6.0, 2.6.1). So the destination of a
> tag
> depends on the source of the tag.
> So there is no way to handle both tag operations with a single tags
> location.

Exactly, and that's why the 'tags' location must be per directory. For the
above example, there could be the following properties:
    svn:tagslocation = /tags
    svn:brancheslocation = /branches
    svn:tagslocation = /vendor/xercesc

The user could give the URLs to /trunk and /vendor/xercesc/current, and
Subcommander could read off the locations for the tags and branches.

Håkon Hallingstad

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 20:31:42 2006

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.