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

Re: Alphe-checklist comments

From: Branko Èibej <brane_at_xbc.nu>
Date: 2001-04-20 01:03:03 CEST

Karl Fogel wrote:

> Branko, these comments all seem worth preserving imho; would you like
> to just annotate alpha_checklist with them?

Will do, over the week-end.

> Regarding repository layouts in the branch|tag == copy scheme, here's
> one way:
>
> /myproject
> /myproject/trunk
> /myproject/branches
> /myproject/tags
>
> So for Subversion, it would be
>
> /subversion
> /subversion/trunk/
> /subversion/branches/
> /subversion/tags/
>
> I think this is simple and foolproof, as you requested. I'll try a
> theoretical justification: coming from CVS, a project has three
> distinct "spaces": mainline commits, branches, and tags. These are
> the only places where historical points get recorded. By replicating
> these three spaces, and keeping them distinct, we must not be losing
> any information, and the pathnames themselves make it fairly intuitive
> what is what.
>
> Well, that's not much of a proof. Mostly I have to just say "It feels
> good to me." Thoughts?

It looks O.K., but what I was getting at is that we have absolutely no
experience with this model. I'm not against merging the concept of
copies, tags and branches. Basically what I'm afraid of is that, unless
we offer a useable example, we'll soon find that every repository will
use a different layout. This would be confusing, especially for users of
public (open source) repositories.

The bright side, as Ben mentioned, is that we can easily move
directories around in Subversion. So I guess we can burn this bridge
when we get to it.

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/
Received on Sat Oct 21 14:36:29 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.