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)
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 -----
> On Fri, Oct 05, 2001 at 04:54:28PM -0500, Ben Collins-Sussman wrote:
---------------------------------------------------------------------
|
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.