I've been reading over the documents on the website and /doc about
branching and tagging, and I have a couple questions that relate to
where Subversion is going to go in response to CVS "vendor tags". If
these have already been discussed somewhere just point me there. I
bring these up as the issues that I've been seeing so far discussed in
the documentation (such as the SVN for CVS users file) is for extremely
simple cases that I've never actually had the pleasure of working with,
and I want to make sure that the more complex cases (such as the one
Zack just outlined in the "Moving C to its own directory" thread, which
would have been my Scenario #3 had it not already been brought up) are
being kept in mind.
Scenario #1:
I maintain a patch for nmap that adds a new -sV command line option, and
it is unlikely to get merged into nmap anytime in the near future. What
I currently do is take each drop of nmap as it is released, and perform
the following steps:
1) Import it into Fyodor's (the original author's) vendor tag: cvs -d
... import -m "Import: nmap-2.54b28" nmap Fyodor nmap-2_54b28
2) Check out a copy of the main branch incorporating the differences
between Fyodor's last release, and Fyodor's current release: cvs -d
... co -j nmap-2_54b27 -j nmap-2_54b28 nmap
3) Remove all of the conflicts and get the checked out copy to compile
(and work correctly, of course).
4) Commit my changes: cvs commit -m "Merged: nmap-2.54b28"
How would this work with Subversion copied directories? Frankly, the
way that CVS supported tags (if not branches) was one of the few
features of CVS I actually liked...
Scenario 2:
I am also working on a 3D engine (the current code branch is called
Optasia, to make it easy to talk about) with a group of people, and have
a rather complex system of DLLs that each take on a specific aspect of
the environment. We also aren't shy about using available third party
libraries that seem strong and sufficiently cross platform. Right now,
the two main libraries that we really rely on are APR and Xerces. Now,
most of the developers of Optasia don't need to be compiling APR or
Xerces all of the time, so we have the DLLs checked into the repository.
However, everyone still needs the header files for the two projects.
The way we are currently doing this is to have a file called
obtain.{bat,sh} in /external which has the versions (in the form of the
date to -D the cvs with) and repositories of the various libraries we
need. It then looks to see if a directory for each library already
exists and uses that to determine if it should do a checkout or an
update.
Now, this method has the following advantages:
1) low maintenance (rather than needing to perform the import, and then
performing the merge and commit you just change the batch file to
include the new date)
2) fast updates (as you only need to query the server for these possibly
massive bricks of code when you run obtain)
3) code purity (if I don't pay attention all the time the people on my
project would likely destroy our repository... they will accidentally
modify files and then commit them all in one batch... needless to say I
don't want this to happen to code that we didn't even write and aren't
going to be able to later maintain well)
However, it also has the following evil disadvantages:
1) isn't automatic (this method actually requires me to yell at people
until they run obtain again if they need new header files)
2) doesn't keep local modifications (in some cases it is nice to be able
to modify a small definition, or in the case of Xalan I have an actual
feature that I patch in, although not for the 3D engine project)
A better way to do this (assuming a good per-directory authorization
scheme in order to keep advantage #3) would be to use vendor tags. In
this case, I would take versions of Xerces that we want and import them
into the repository at /external/apr (for example) under the vendor tag
Apache, and then merge them into the main branch. This way we would
always have a copy of the libraries (in case a router at Apache HQ blows
up) and we can also make minor local changes to things like workspaces.
This is definitely how I would _like_ to do this when I start using
Subversion in earnest at some point. The main reason I'm not doing
something along these lines already is because I didn't think of it
before.
However, it gets more annoying than this. Someone needs to actually
_compile_ these DLLs that get put in the repository. This person needs
the complete copy of the sources rather than just the include files (so
no just getting xalan/src/include or whatever it was) and, if we are
keeping local modifications, is going to need synced local modifications
on the header files as well as extra modifications. What would be good
here is to be able to keep all of the code for these other projects on
the server.
So, the way I'd like to deal with this (working off of some of what Zack
was saying with how he's thinking of "symbolic links", even though I am
pretty sure that that was a slight misinterpretation of the
documentation about being able to commit a Unix symlink...) is to have a
/libs directory under the root of my subversion that contains the
original copies of the various libraries that we are using. In the main
trunk there would be a directory 'external' which would contain links to
the include directories of other projects (or the entire things in the
cases where the authors didn't think that someone might just want the
include folder easily, such as is the case with APR). There would also
be another directory /binaries (or something, can't think of just the
right name) which has a directory for debug, release, and staging builds
(under /binaries/bin) of the various external libraries, and a (possibly
modified) copy of the various libraries (which is only writable by the
person in charge of maintaining external libraries, to help with the
previously mentioned "code purity"). The /binaries/bin folder would be
linked to from /trunk as well.
When a new release of a library came out I would then import that
library into the repository and it would be available under /libs. I
could then merge the changes made between it and the previous version
into the modified version under /binaries (i.e., like a vendor import).
Just thinking about being able to separate all of the concerns like that
gives me a general warm fuzzy feeling :).
Thinking about it, I could actually come rather close to this "ideal"
with the current implementation of CVS (hell, closer depending on how
Scenario #1 works out). I could have each library in a separate module
on the server and then have symbolic links in the actual server
repository to do the "links" as mentioned here. The aforementioned
authentication issue could be done by having an actual system account
and having CVS map the authorization to that. In fact, if it wasn't for
the fact that I so desperately wanted directory versioning I'd probably
just go off and do that and leave all you people alone :). Actually,
I'm feeling so good about this that I might have to anyway, hehe.
So, my question here is: where is Subversion going to deal well with
_that_? ;-P
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
---------------------------------------------------------------------
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:49 2006