> 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
Received on Mon Jul 10 11:26:12 2006