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

Re: Cloning, branching, and cvs2svn

From: roger day <roger_at_nenuphar.freeserve.co.uk>
Date: 2001-10-06 15:36:49 CEST

That half-answers my question - I suppose linking (whatever that would be in svn terms) would get me to where I wanted to get to.

I have to come clean in the fact that I work with/help maintain a SCCS called "HOPE" - it's a very mature bespoke project which we are looking to replace - actually we're looking at perforce, but it has certain disadvantages. One of these disadvantages is the lack of connection between "projects" - actually, HOPE calls them "compounds" (a logical collection of units - a unit being a logical representation of a file). This allows us to have compound trees such that:-

Compound A(Branch a) ( ==The parent compound)
    |
   V
Compound B(Checkpoint b) ( ==The child compound)

Development can continue along the line Product A(branch A), but development - beyond bug fixes - has stopped in Compound B(checkpoint b) - this being a time-slice along a product's development tree (I'm assuming that "tags" are similar to checkpoints).

IMO, the idea of compounds is quite attractive - for a start, it's an abstraction -away- from directories - and directories as a concept has the quality of simplicity for explanation - but against that, it has all kinds of baggage (links etc) and different meanings under different systems. I think the -idea- of compounds in HOPE has been one of it's successes. It's implementation, less so.

To explain, the major way in which compounds differ from the below diagram is that a compound can be referenced from several other compounds. Once one project is referenced by or references several projects, then the below diagram represents only one particular view onto the whole collection of projects that a company might have.

Given this, it makes sense for the server-side data-representation to be flat at the project level - the view only becomes concrete once the user checks the whole tree onto the local disk/local file system.

The logical view of the unit also comes into play as well - a unit name in HOPE can contain a directory hierarchy as well represented thusly -

unit name = "a:b:c:d.txt"

where a, b and c are directories on the disk. The file name in the server-side store might only be "d.txt,v" - once checked out it becomes

a/b/c/d.txt

This allows for a lot of flexibility.

As an implementation, it looks like hard links for directories might cover what I'm looking for - espeicially if the client can distinguish between the project links and "unit" links - that is if you allow for the latter in your design.

Sorry to go on at length about this.

Roger.

----- Original Message -----
From: "Greg Stein" <gstein@lyra.org>
To: "roger day" <roger@nenuphar.freeserve.co.uk>
Cc: <dev@subversion.tigris.org>
Sent: Saturday, October 06, 2001 01:33
Subject: Re: Cloning, branching, and cvs2svn

> On Fri, Oct 05, 2001 at 04:54:28PM -0500, Ben Collins-Sussman wrote:
> > "roger day" <roger@nenuphar.freeserve.co.uk> writes:
> >
> > > A newbie question. Will your projects be linked in some way? Could
> > > I, say, get to have a tree of (sub-)projects in subversion? Sorry if
> > > this question has risen before.
> >
> > I'm not sure what you're asking, so I apologize if I answer the wrong
> > question.
> >
> > The repository is an ordinary filesystem. It has an arbitrary
> > directory structure. You can arrange things however you want. The
> > repository has no knowledege that any particular directory is a
> > "project", or "branch", or "tag". They're all just directories.
>
> Right. So a person could easily set up:
>
> /
> super-project/
> sub-project-1/
> sub-project-2/
> sub-project-3/
> trunk/ ; trunk of sub-project-3
> branches/ ; branches of -3
> tags/ ; tags for -3
> tags/ ; tags for the whole super-project
>
>
> However you want to arrange it. It is just a set of directories.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 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.