Thank you all very much for your thoughts on modules, especially
when you are busy with M3. I think I have a fairly clear picture now,
and here are some early ideas on the subject.
Let's have an example with:
mod/mod.c
foo/foo.c
foo/mod/mod.c
bar/bar.c
bar/mod/mod.c
and see what happens with the different kinds of modules.
I'll define those as "static" vs "dynamic", and "linked" vs "included".
1. Dynamic, included
____________________
Check in a change to mod.c, check out foo or bar:
- get the new mod.c
Branch foo or bar:
- mod is branched, and the branches of foo or bar
include the corresponding branch of mod.
2. Dynamic, linked
__________________
Check in a change to mod.c, check out foo or bar
- get the new mod.c
Branch foo or bar:
- mod is not branched
3. Static, linked
_________________
Check in a change to mod.c, check out foo or bar
- still get the old mod.c
Branch foo or bar:
- mod is not branched
4. Static, included
___________________
Check in a change to mod.c, check out foo or bar
- still get the old mod.c
Branch foo or bar:
- mod is branched, and the branches of foo or bar
include.... hmm. More on this later.
(1) is the system I used for many years when I worked at
Harlequin (the Hqn that makes a PostScript interpreter,
not the romance publishers), and I thought all source
control systems worked like that.
(2) is "vnodes" as elucidated by Yoshiki, where the vnode
contains a node id.
(3) is like (2) but the vnode contains a node *revision* id.
(4) is, now that I come to think about it, confusing and
probably completely useless. I certainly don't have any
pressing need for it, unlike the others.
The more I think about this, the less I see an urgent
need for (1). Harlequin's system (called HOPE) did not
use directories as CVS did; instead there were entities
called "compounds" floating about in the system, not
arranged in the repository in any way that was visible
from outside. They contained files. If you asked HOPE
to check out a compound, it created a directory and put
the files into it. As well as files, compounds could
contain other compounds. These sub-compounds were shared
as in my example. If you checked out a compound recursively,
the sub-compounds went into sub-directories. We used
sub-compounds for three distinct purposes:
A. to organise the code. CVS and SVN use directories for this.
B. to share code for particular functions among different
programs in the same product family. All the programs
would be branched together.
C. to share interfaces between programs. For this, the branching
behaviour was quite unsuitable. We ended up with far too many
identical copies of the interface definitions, and it was too
easy to change the copy used by one program but not another,
so the programs had incompatible definitions.
(It was this third problem (C) that led me to request "linked"
as opposed to "included" sub-compounds. It turned out to be
very easy to implement this by allowing tags to be used when
defining a sub-compound: instead of saying "add module M
branch B", say "add module M tag T". That gave behaviour 3,
static used modules. This was fine for most purposes, but
problematic for the trunk, where development was taking place
continually both in the programs and in the interfaces. People
ended up moving tags all the time. This was not only tiresome
to do, but it broke the invariant that says you should always
get the same result if you check out the same revision. For
instance, on Monday, check out foo and get mod, tag T. On Tuesday
redefine T. On Wednesday, check out foo using Monday's revision;
it still says to use revision T of foo, but that no longer means
the same thing.)
Returning to the consideration of behaviour (1), dynamic included
modules: for purpose (A), we can use directories. For (C), we should
use linked modules instead; static for stable interfaces, dynamic
during early development. That just leaves (B), and I can't help
feeling that there are plenty of other ways of sharing code that
are at least as good.
In conclusion, your symbolic virtual entry links are just the thing!
I'll try and think of a good name for them :-)
... okay: how about "reference"?
So, a static reference is a node that contains the node revision id
of another node. A dynamic reference is a node that contains a node id.
To get an actual node revision id, use the revision that you used when
coming down from the root. E.g, if you check out revision 2 of foo,
you get rev 2 of mod as well. [I understand that you can't just stick
"2" on the end of the node id - you need to see which node revision
was current in repo rev 2].
How does that sound?
If you like it, is anyone working on it, or would you like a volunteer?
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:35 2006