You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Danny van Heumen <da...@hccnet.nl> on 2006/07/08 18:15:10 UTC
Re: Special support for tags and branches
hakon@ion.no wrote:
> You were right. I gather from the emails in this thread that we should
> build upon the current Subversion-like tags. And I believe we could agree
> on the following 4 principles:
>
> 1. A better tagging system must be based on the current Subversion-like tags.
>
> 2. We should include branches and 'projects' into the discussion.
I "disagree".
I think the discussion should be _based upon_ the layout of the
repository not just about Tags (and branches and projects). Tags and
branches are just part of this layout and AFAICT it's the layout that
bugs people.
I think that people want to change branching/tagging because they don't
like the idea of tags and branches being visibly available in their
repository like other files are. (I think it's a kind of fear the rises
because 'you can see!' the tag or branch, so it's not a real tag/branch.)
A property isn't directly visible so it makes the concepts 'tags' and
'branches' more abstract like they are for example in CVS.
BTW: I get the idea that the fact that you don't check out the root
folder of a repository scares some people too. (At least some of my
fellow students insisted on checking out the complete repository every
time :P, especially those who were used to CVS.)
To get back to the point... I think that we need to document some 'Best
Practices' of repository layouts that can be used for different scenarios.
We can use these repository layouts as a base for working towards a tool
or extension of svn.
> 3. Clients should be able to locate and identify 'projects', branches and
> tags. The need for this is exemplified by Subclipse
I think we should watch out with the word 'project'. Although both tags
and branches are our own ideas they have a basis in the SVN Cheap
Copies. A 'project' is what someone thinks is a single project. But it's
nothing tangible for SVN. I agree that we have such a thing as a
'project' but without a clear definition we could think in different ways.
(Probably just like the way we thought differently about tags ;) )
> 4. The Subversion commands and libraries should be extended to maintain
> and use the meta-information provided by (3). This will finally enable us
> to simplify typical Use Cases, like tagging the trunk.
If we cover that base correctly and completely we can built tools based
on this information. I think it's important to have the documentation
available because we want to learn people why we they should use these
layouts, and not just automagically generate them or something like that :D
> Based on these, I have the following ideas:
I think we're rushing a bit here... :P
>
> PROJECTS
>
> A 'Project' directory contains properties for the location of the 'trunk',
> 'branches' and 'tags' directories. The following properties should be
> specified for a Project directory:
>
> 1.1. "svn:project"*
>
> 1.2. "svn:tags-location", with a value of e.g. "/svn/tags@456"
>
> 1.3. "svn:branches-location" with a value of e.g. "/svn/branches@678"
>
> 1.4. "svn:trunk-location" with a value of e.g. "/svn/trunk@234"
>
> *) The property "svn:project" defines a Project directory. The value of it
> could be a description of the project, copyright information, contact
> information, ...
>
> TAGS
>
> All tag directories below the Project's "svn:tags-location" directory
> should have a property "svn:tag", with a value of e.g. "/svn/trunk@1452"
> of the source of the tag.
>
> In addition, each tag directory should have a property
> "svn:project-location", e.g. with value "/svn@123".
>
> BRANCHES
>
> All branch directories below the "svn:branches-location" directory should
> have a property "svn:branch", e.g. with the value "/svn/trunk@1567" for
> the source of the branch.
>
> The "svn:trunk-location" directory should have a "svn:trunk" property,
> similar to the "svn:branch" property, but the value of "svn:trunk" will
> usually be empty.
>
> In addition, each tag directory should have a property
> "svn:project-location", e.g. with value "/svn@123".
>
> RESOLUTION OF REFERENCES
>
> Say I want to find the 'diff' between the tag 'version-1.0' and the
> current working directory. The following shows how 'version-1.0' could be
> resolved to a URL:
>
> 1. "version-1.0" is recognised as a tag.
> 2. Walk up the local directory tree until I find a "svn:tag-location".
> 3. The value of that property identifies the 'tags' directory.
> 4. However, that directory may be located elsewhere in HEAD, so I find
> (somehow) the current location of the 'tags' directory.**
> 5. To the current tags location, I append "/version-1.0".
>
> **) Is this operation fast?
>
> EXTENDING THE COMMANDS
>
> We need to provide commands that will use and support these properties.
> There are some options:
>
> 1. Make new commands, e.g. 'svn tag'.
>
> 2. Extend the syntax for TARGETs, e.g. "@version-1.0" or
> "tag://version-1.0" could expand to
> "http://svn.collab.net/repos/svn/tags/version-1.0" based on the Project's
> "svn:tags-location".
>
> 3. Extend the current commands with more options, e.g. the option '-t'
> could mean the second argument to 'cp' should be interpreted relative to
> the tag container directory. So a command could look like "svn cp -t .
> version-1.0".
>
> (2) is probably sufficient, but (1) is more flexible.
>
> Håkon Hallingstad
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by John Peacock <jp...@rowman.com>.
Martin Hauner wrote:
> It's just a convenience function for those that use the subversion layout.
> I don't know if anyone is really using it.
I'm using and it works great! Expand the project, right click on trunk,
choose Tag and the requester comes up with the project tag directory
already selected.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by Danny van Heumen <da...@hccnet.nl>.
hakon@ion.no wrote:
> If the user wants to tag a subdirectory, then that's another Project, as
> per definition of 'Project' (mine and Subcommander's).
That sounds kinda logical.
> The Apache Software Foundation repository uses this technique of 'nested
> Projects'. For example the Project /db/torque has a nested Project
> /db/torque/common.
>
> But if the user has not setup the subdirectory as a Project, then we
> should give him an error message so he can act on it.
Ok, so we're limiting his action and force him to think about what he's
doing. (Of course not a final limit, because he can always manually 'svn
copy'.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by ha...@ion.no.
> hakon@ion.no wrote:
>> Exactly, and that's why the 'tags' location must be per directory. For
>> the
>> above example, there could be the following properties:
>> /trunk:
>> svn:tagslocation = /tags
>> svn:brancheslocation = /branches
>> /vendor/xercesc/current:
>> 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.
> Ok, this sounds good.
>
> Another thing: what should happen when someone selects a subdirectory
> from trunk to tag? Because you've indicated in 'trunk' with the property
> "svn:tagslocation" where tags will be stored, but we haven't done that
> for any subdirectories. (Or have we?)
>
> Do you want an error, tell them that there's no 'svn:tagslocation'
> information available, or should we look in parent directories for
> 'svn:tagslocation', or should we just let the user choose?
>
> (I'm just deepening out the idea a little, because I think we're on the
> right track here.)
If the user wants to tag a subdirectory, then that's another Project, as
per definition of 'Project' (mine and Subcommander's).
The Apache Software Foundation repository uses this technique of 'nested
Projects'. For example the Project /db/torque has a nested Project
/db/torque/common.
But if the user has not setup the subdirectory as a Project, then we
should give him an error message so he can act on it.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by Danny van Heumen <da...@hccnet.nl>.
hakon@ion.no wrote:
> Exactly, and that's why the 'tags' location must be per directory. For the
> above example, there could be the following properties:
> /trunk:
> svn:tagslocation = /tags
> svn:brancheslocation = /branches
> /vendor/xercesc/current:
> 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.
Ok, this sounds good.
Another thing: what should happen when someone selects a subdirectory
from trunk to tag? Because you've indicated in 'trunk' with the property
"svn:tagslocation" where tags will be stored, but we haven't done that
for any subdirectories. (Or have we?)
Do you want an error, tell them that there's no 'svn:tagslocation'
information available, or should we look in parent directories for
'svn:tagslocation', or should we just let the user choose?
(I'm just deepening out the idea a little, because I think we're on the
right track here.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by ha...@ion.no.
>> 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:
/trunk:
svn:tagslocation = /tags
svn:brancheslocation = /branches
/vendor/xercesc/current:
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
Re: Special support for tags and branches
Posted by Martin Hauner <ma...@gmx.net>.
Hi,
hakon@ion.no wrote:
> In Subcommander, the user has to write the tags- and branches- URL, in
> addition to the trunk URL. (Or click on a 'standard project layout' button
> to choose the common tags/, branches/ and trunk/ layout.)
You don't have to set the urls but it helps when creating new branches
and tags in the most common case.
> Have you
> received any feedback on the need to write in the three URLs? Is that why
> you put in a 'standard project layout'?
It's just a convenience function for those that use the subversion layout.
I don't know if anyone is really using it.
> 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.
--
Martin
Subcommander 1.1.0 - http://subcommander.tigris.org
a cross platform Win32/Unix/MacOSX subversion GUI client & diff/merge tool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by ha...@ion.no.
In Subcommander, the user has to write the tags- and branches- URL, in
addition to the trunk URL. (Or click on a 'standard project layout' button
to choose the common tags/, branches/ and trunk/ layout.) Have you
received any feedback on the need to write in the three URLs? Is that why
you put in a 'standard project layout'?
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?
And what do you think of making special commands in Subversion for tagging
and branching, which utilizes the properties.
>>> 3. Clients should be able to locate and identify 'projects', branches
>>> and
>>> tags. The need for this is exemplified by Subclipse
>> I think we should watch out with the word 'project'. Although both tags
>> and branches are our own ideas they have a basis in the SVN Cheap
>> Copies. A 'project' is what someone thinks is a single project. But it's
>> nothing tangible for SVN. I agree that we have such a thing as a
>> 'project' but without a clear definition we could think in different
>> ways.
>> (Probably just like the way we thought differently about tags ;) )
>
> I agree that 'project' is not well-defined. When I used the word 'Project'
> (with capital P) in the original email, I meant the collection of a trunk,
> its branches and its tags. I.e. it is a 'cut' or 'branchpoint' in the
> repository tree you want to tag or branch. This does not necessarily
> correspond to the user's perception of her project.
>
> In this case of Subversion, I like to think of
> "http://svn.collab.net/repos/svn" as the 'project URL'.
>
> But in the case of a /trunk, /tags and /branches layout, there is no
> simple 'Project URL'. If we are to follow other VCS' notion of such a
> 'Project', then the trunk defines the Project, because the branches and
> tags are hidden. This would mean /trunk/svn would be the 'Project URL'.
>
> A 'Project URL' is nice to have, because it defines the location of the
> trunk, tags and branches. So you could pass one URL to a GUI, and it could
> present you with a list of tags, a list of branches, and the immediate
> option of checking out the trunk.
By the way, Subcommander defines a 'project' in the exact same way. (But
Subcommander also puts working copies of the 'branchpoint' into the
project definition.)
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by ha...@ion.no.
>>>> 4. The Subversion commands and libraries should be extended to
>>>> maintain
>>>> and use the meta-information provided by (3). This will finally enable
>>>> us
>>>> to simplify typical Use Cases, like tagging the trunk.
> Please think about a separate application/tool. Because we're actually
> building some sort of a layer around the subversion base. And I don't
> think it is wise to build this directly into subversion itself.
Your wizard should (of course) not be a part of Subversion.
Support for tagging and branching is such an integral part of any VCS, and
every client needs an API to it. Currently the 'copy' interface is used,
but if we are going to make special support for tags and branches the new
interface should be exposed to all Subversion clients.
I have difficulty seeing the "special support for tags and branches"
become a de facto standard, if it is not included in the standard
installation of Subversion.
However, this will all depend on what the list is able to agree on. We
will see.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by Danny van Heumen <da...@hccnet.nl>.
hakon@ion.no wrote:
> How is the documentation of 'Best Practices' going to make Subversion's
> branching and tagging interface easier? I think you are trying to solve a
> different problem.
It's not ;)
But it is going to make clear to the users that Subversion's branching
and tagging support needs more that just a mouse-click (or a single
command).
And it's not that I'm trying to solve a different problem. It's more
that I'm trying to solve the problem from the roots.
I get the feeling that you're looking solely at the interface of tagging
and branching. I, on the other side, am looking at the complete picture
(interface, directory structure, SVN implementation vs other RCS). I'm
doing this because there were also some mails from people that don't
understand (or don't want to ;) ) why tags and branches are essentially
the same (except for the convention not to change a tag).
But for the sake of progress I'll travel on that little adventure alone
for a while, so I won't hold you up ;).
> I agree that 'project' is not well-defined. When I used the word 'Project'
> (with capital P) in the original email, I meant the collection of a trunk,
> its branches and its tags. I.e. it is a 'cut' or 'branchpoint' in the
> repository tree you want to tag or branch. This does not necessarily
> correspond to the user's perception of her project.
Good point, because I was already thinking in the wrong way.
One difficult point is the fact that some people use this directory layout:
/trunk/{project1}
/trunk/{project2}
/tags/{project1}
/tags/{project2}
/branches/{project1}
/branches/{project2}
(Btw: not talking about 'Project' here, I'm talking about project in the
old form)
The problem you get when you give every project a separate
trunk/tags/branches layout, is that you can't branch several projects.
And this could be necessary if you have project that are dependencies of
each other. (Just so we don't forget about this possible layout.)
> In this case of Subversion, I like to think of
> "http://svn.collab.net/repos/svn" as the 'project URL'.
>
> But in the case of a /trunk, /tags and /branches layout, there is no
> simple 'Project URL'. If we are to follow other VCS' notion of such a
> 'Project', then the trunk defines the Project, because the branches and
> tags are hidden. This would mean /trunk/svn would be the 'Project URL'.
>
> A 'Project URL' is nice to have, because it defines the location of the
> trunk, tags and branches. So you could pass one URL to a GUI, and it could
> present you with a list of tags, a list of branches, and the immediate
> option of checking out the trunk.
I agree: we should have some sort of a 'home base' to work from.
>>> 4. The Subversion commands and libraries should be extended to maintain
>>> and use the meta-information provided by (3). This will finally enable
>>> us
>>> to simplify typical Use Cases, like tagging the trunk.
Please think about a separate application/tool. Because we're actually
building some sort of a layer around the subversion base. And I don't
think it is wise to build this directly into subversion itself.
> I am not assuming any particular layout of the repository, I leave that to
> you to document best practices.
Yep, that's my journey :D
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Special support for tags and branches
Posted by ha...@ion.no.
> hakon@ion.no wrote:
>> You were right. I gather from the emails in this thread that we should
>> build upon the current Subversion-like tags. And I believe we could
>> agree
>> on the following 4 principles:
>>
>> 1. A better tagging system must be based on the current Subversion-like
>> tags.
>>
>> 2. We should include branches and 'projects' into the discussion.
> I "disagree".
> I think the discussion should be _based upon_ the layout of the
> repository not just about Tags (and branches and projects). Tags and
> branches are just part of this layout and AFAICT it's the layout that
> bugs people.
>
> I think that people want to change branching/tagging because they don't
> like the idea of tags and branches being visibly available in their
> repository like other files are. (I think it's a kind of fear the rises
> because 'you can see!' the tag or branch, so it's not a real tag/branch.)
>
> A property isn't directly visible so it makes the concepts 'tags' and
> 'branches' more abstract like they are for example in CVS.
>
> BTW: I get the idea that the fact that you don't check out the root
> folder of a repository scares some people too. (At least some of my
> fellow students insisted on checking out the complete repository every
> time :P, especially those who were used to CVS.)
>
> To get back to the point... I think that we need to document some 'Best
> Practices' of repository layouts that can be used for different scenarios.
> We can use these repository layouts as a base for working towards a tool
> or extension of svn.
How is the documentation of 'Best Practices' going to make Subversion's
branching and tagging interface easier? I think you are trying to solve a
different problem.
>> 3. Clients should be able to locate and identify 'projects', branches
>> and
>> tags. The need for this is exemplified by Subclipse
> I think we should watch out with the word 'project'. Although both tags
> and branches are our own ideas they have a basis in the SVN Cheap
> Copies. A 'project' is what someone thinks is a single project. But it's
> nothing tangible for SVN. I agree that we have such a thing as a
> 'project' but without a clear definition we could think in different ways.
> (Probably just like the way we thought differently about tags ;) )
I agree that 'project' is not well-defined. When I used the word 'Project'
(with capital P) in the original email, I meant the collection of a trunk,
its branches and its tags. I.e. it is a 'cut' or 'branchpoint' in the
repository tree you want to tag or branch. This does not necessarily
correspond to the user's perception of her project.
In this case of Subversion, I like to think of
"http://svn.collab.net/repos/svn" as the 'project URL'.
But in the case of a /trunk, /tags and /branches layout, there is no
simple 'Project URL'. If we are to follow other VCS' notion of such a
'Project', then the trunk defines the Project, because the branches and
tags are hidden. This would mean /trunk/svn would be the 'Project URL'.
A 'Project URL' is nice to have, because it defines the location of the
trunk, tags and branches. So you could pass one URL to a GUI, and it could
present you with a list of tags, a list of branches, and the immediate
option of checking out the trunk.
>> 4. The Subversion commands and libraries should be extended to maintain
>> and use the meta-information provided by (3). This will finally enable
>> us
>> to simplify typical Use Cases, like tagging the trunk.
> If we cover that base correctly and completely we can built tools based
> on this information. I think it's important to have the documentation
> available because we want to learn people why we they should use these
> layouts, and not just automagically generate them or something like that
I am not assuming any particular layout of the repository, I leave that to
you to document best practices.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org