subversion module system question

I've only recently been pointed at Subversion by a coworker, but I have
a long-standing love/hate relationship with CVS. Mostly I love CVS, it's
really good at a lot of things. One of the 'hate' bits has over time
become a topic near and dear to my heart, as it's bitten my lab in the
butt yet again recently: the CVSROOT/modules file.

I read the discussion of issue #517 and the related recent dev thread
but may have missed some additional discussions. Perhaps someone (maybe
Karl, maybe not, he sounds like the person in charge of the issue even
though I'm sure he's a busy guy) could clarify some of what I've read.

With CVS modules I have had pretty specific and predictable problems;
parent modules which depend upon stable APIs of a child tend to have
children drift out from under them, and there's no way of specifying
what branch or static tag version of the child is really wanted by a
parent. Also removing submodules is basically the eighth deadly sin
because branching/tagging/etc a module in the repository is completely
independent of doing so with the declaration of submodules.

I really, _really_ like the idea of having a submodules file (named
whatever but with a special property) that lists the svn checkout
arglists for each submodule of a module. It sounds like it would prevent
99% of the problems I've ever had with the CVS modules file. I'm really
honestly not sure what a "reference node" type would add. That said,
there are some lingering questions in my mind, though, on how the
planned functionality will end up.

--
a) Can such a file just be a file in a regular repository module, and
activate on checkout or update of the module it resides in?
Just having a modules file sounds like it keeps the modules file
separate from files that may be sitting in the same directory as the
submodules should appear in, like
modules\mymod <- check this out to get all the following
parent\foo.h
parent\submodule1\argle.h
I would like the option of the following, but (maybe with some good
reason I didn't think of) nobody has mentioned it. Maybe I missed it,
maybe the assumption is that it will be possible, I dunno.
parent\foo.h
parent\mysubmods <- when parent is checked out this is activated
parent\submodule1\argle.h
Now, I don't fully understand the property thing, so it's not clear if
the properties are version controlled in the same manner as a
fully-formed modules file would be, but unless dealing with properties
is a day-in, day-out activity with SVN that everyone does I'd just as
soon have a file.
--
b) Can the default behavior of checkouts and updates etc in a system
with submodules be decided based on the nature of the checkout options
in such a file? (or as if there was a file, if no file actually
manifests in the final design -- there was some suggestion that
submodules just be properties on the parent's directory, and the final
decision on that wasn't clear)
i.e. if I have a submodule checked out at some specific revision that
has an API that I depend upon, I want that revision used until I modify
my submodules file, and updates shouldn't affect it. Similarly I
*should* be prevented from committing changes in that submodule, because
semantically I should be operating with a read-only copy of that
submodule anyway, and if I'm changing the readonly attribute I should
also be warned to change my checkout options on the submodule to use a
branch version instead of a specific revision (I know, I'm confusing CVS
terminology and SVN terminology, I apologize). If in the submodules file
I just get the latest version of some branch of a submodule, then
updating and committing should DWIM, etc.
Probably all of this will just happen once the system is checked out
properly, because of the SVN control files (just like in CVS), right?
The only difference is that there's a file that you can modify to add
and remove submodules, or change the version or branch of a submodule
that is used depending on what branch of the parent is being developed.
--
Not big questions, mostly, since I understand the issues with the way
CVS works only too well.
hamilton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org