Roger,
Have a look in the archives of the mailing list at
<http://subversion.tigris.org/servlets/BrowseList?listName=dev&paged=false>
starting around 2001-07-31, thread "Intro and questions".
On 2001-10-06 14:36:49 "roger day" wrote:
>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
...
>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.
I have actually been thinking about your specific problem,
believe it or not, because I am also looking to replace an
aging source control system. Last week I spent some time
thinking about how to use Subversion to implement what you
have in HOPE. Directories in units, and links, can do what
you need. There are two cases: one where you have a library
which has a well-defined interface, such that it can have
its own schedule of releases, and one where the shared
compounds are horrible entangled with the parent products.
I'm copying this to the list because I said I would work
on use cases, and this is a fine example of solving a real
live problem using Subversion.
Before I start, a word about terminology: in message
<http://subversion.tigris.org/servlets/ReadMsg?msgId=33783&listName=dev>
kfogel said about the idea of links:
"Since Subversion will version real symlinks in the expected way,
we should be careful to avoid using the same term for the
unrelated feature Yoshiki describes above. (Mike, Ben, and I
have been calling them "vnodes" or "virtual entries", but maybe
a better name will suggest itself?)".
I suggested the name "references", and that's what I shall
call them below.
First case: shared code with a clean interface.
This one is easy. Your products and libraries live in
different directories, and the products have references
to the libraries.
prod1/branch_p1/owncode/foo.c
prod1/branch_p1/lib1 -> "lib1"
prod1/branch_p1/lib2 -> "lib2"
lib1/branch_a/lib1.c
lib2/branch_x/lib2.c
Notes:
1.you could organise it as "branch_p1/prod1" if you
really wanted to; it doesn't matter for the example.
2.foo.c is in a subdir just to show that you can use
directories to organise your code. HOPE has to use
gratuitous sub-compounds for this.
The Subversion equivalent of branching the product is to
clone the "branch_p1" directory:
prod1/branch_p1/owncode/foo.c
prod1/branch_p1/lib1 -> "lib1/branch_a"
prod1/branch_p1/lib2 -> "lib2/branch_x"
prod1/branch_p2/owncode/foo.c
prod1/branch_p2/lib1 -> "lib1/branch_a"
prod1/branch_p2/lib2 -> "lib2/branch_x"
lib1/branch_a/bar.c
lib2/branch_x/baz.c
The references to the libs are copied, but the libs are not.
This is just as it should be, since they are separate products.
Second case: several products share code using HOPE sub-compounds.
All the products know too much about the shared code, call in to
supposedly private functions, use extern variables they shouldn't,
and so on, so you can't manage the shared code separately. If you
branch the products (in Subversion, clone them) you have to branch
the libraries with them. So you do this:
relatedproducts/branch1/prod1/owncode/foo.c
relatedproducts/branch1/prod1/makefile
mentions "../shared/lib1" and lib2.
relatedproducts/branch1/prod1/owncode/foo.c
relatedproducts/branch1/prod1/makefile
mentions "../shared/lib1" and lib2.
relatedproducts/branch1/shared/lib1/bar.c
relatedproducts/branch1/shared/lib2/baz.c
Then, when you want to make a branch, clone the
whole thing to give relatedproducts/branch2.
Note that I haven't used references here.
If references use absolute paths (or rather
node ids, because paths are changeable),
branch2 will end up using the same libs as
branch1. You would have to fix up the refs
by hand (as you do in HOPE at the moment if
you do a non-recursive branch). Refs can't be
relative, because a) they would break when
moved or copied, and b) there's no such thing
as a relative node id.
Actually, there's a third case: several products
use a library with a very well-defined interface
and release structure. Each product knows which
revision of the library it wants to use. In HOPE
this would be a component; in Subversion it would
be a "static reference", which is a reference to
a particular revision of a node - if I can persuade
this community that this would be a good idea!
Peter.
---------------------------------------------------------------------
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