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