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
Received on Sat Jul 8 20:15:26 2006