You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hamilton Link <he...@sandia.gov> on 2002/05/21 20:35:57 UTC
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
Re: subversion module system question
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> $ svn cp -r 1000 /trunk /module-snaps/rev1000
> $ svn propedit /modules/mutha
> (add line:
> /somelib /module-snaps/rev1000/foo/somelib
> )
> $ svn commit /modules/motha
>
> IOW, to pin a particular revision for containment within the module, you
> make a copy to somewhere, and then refer to the (pinned) copy.
Ick! I see what you meant now.
> That is called a "user strategy" and is Badness(tm).
:-) Heh, I'd never heard that expression before.
No, we're doing it the other way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Ben Collins-Sussman <su...@collab.net>.
"Mats Nilsson" <ma...@xware.se> writes:
> > > Please set me straight. Why is this considered Badness:
> > > svn cp -r 1000 /trunk /module-snaps/rev1000
> > >
> > > while this is not?
> > > svn cp -r 1000 /trunk /tags/foobar-1.0
> >
> > Greg's not saying that using 'svn cp' to create
> > tags/branches/cheap-copies is a Badness.
> >
> > He's saying that it's Bad for a module system to *require* that you
> > make a cheap-copy, so that a particular module can always point to
> > that location in HEAD.
> >
> > Instead, a particular module is simply going to point to (revision,
> > path) pairs. No copies required.
>
> I had to ask, since I've got the impression that the "a tag is a cheap copy"
> mantra has been defended quite intensely. Now during the switch, diff and
> module design discussions, all the sudden a quite different idea is
> stealthily introduced - that you can refer to a point in space and time
> *without* making a copy.
This is not a new idea. A (revision, path) pair is a universal
concept... it's the way to locate anything in the repository. Usually
we just imply HEAD revision.
> As someone noted a few days ago, modules can be a way of introducing a tag
> concept for those uncomfortable with making a copy to mark a tag. Maybe it
> would be better to introduce tags as a first class citizen object (something
> other than being equal to a cheap copy), if that level of detail is what an
> increasing number of commands and features require. Now, only modules will
> benefit from sneak-mode tags a.k.a module entries.
Tags are first class citizen objects -- they're ordinary directories. :-)
> I'm not saying that the current suggestion is bad, just that it is diluting
> the quite pure filesystem model. And I will still be able to make a cheap
> copy tag and refer to its HEAD.
It's perfectly fine for a module to point to a tag-directory in HEAD.
People can do that if they want. Greg Stein was simply saying that we
not *force* people do to that when defining a module. In other words,
he was making sure that a module is *able* to point to an arbitrary
(rev, path) location, rather than only being able to point to
locations in HEAD.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>"Mats Nilsson" <ma...@xware.se> writes:
>
>
>>I'm not saying that the current suggestion is bad, just that it is diluting
>>the quite pure filesystem model. And I will still be able to make a cheap
>>copy tag and refer to its HEAD.
>>
>>
>
>I think the current system doesn't dilute the filesystem model at all,
>as it's entirely client-side.
>
>There's no way (currently) to make a copy of a floating target. If
>you make a copy of HEAD, then your copy will no longer point to HEAD
>as soon as someone starts committing. The main advantage of the
>module system is that it allows one to pin one dimension (the path)
>without being required to pin the other (the revision).
>
>
And there's also the Tiny Little Detail that your module might point to
an external repository you don't have write permission to, so you
/can't/ create a copy there.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Mats Nilsson" <ma...@xware.se> writes:
> I'm not saying that the current suggestion is bad, just that it is diluting
> the quite pure filesystem model. And I will still be able to make a cheap
> copy tag and refer to its HEAD.
I think the current system doesn't dilute the filesystem model at all,
as it's entirely client-side.
There's no way (currently) to make a copy of a floating target. If
you make a copy of HEAD, then your copy will no longer point to HEAD
as soon as someone starts committing. The main advantage of the
module system is that it allows one to pin one dimension (the path)
without being required to pin the other (the revision).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: subversion module system question
Posted by Mats Nilsson <ma...@xware.se>.
> > Please set me straight. Why is this considered Badness:
> > svn cp -r 1000 /trunk /module-snaps/rev1000
> >
> > while this is not?
> > svn cp -r 1000 /trunk /tags/foobar-1.0
>
> Greg's not saying that using 'svn cp' to create
> tags/branches/cheap-copies is a Badness.
>
> He's saying that it's Bad for a module system to *require* that you
> make a cheap-copy, so that a particular module can always point to
> that location in HEAD.
>
> Instead, a particular module is simply going to point to (revision,
> path) pairs. No copies required.
I had to ask, since I've got the impression that the "a tag is a cheap copy"
mantra has been defended quite intensely. Now during the switch, diff and
module design discussions, all the sudden a quite different idea is
stealthily introduced - that you can refer to a point in space and time
*without* making a copy.
As someone noted a few days ago, modules can be a way of introducing a tag
concept for those uncomfortable with making a copy to mark a tag. Maybe it
would be better to introduce tags as a first class citizen object (something
other than being equal to a cheap copy), if that level of detail is what an
increasing number of commands and features require. Now, only modules will
benefit from sneak-mode tags a.k.a module entries.
I'm not saying that the current suggestion is bad, just that it is diluting
the quite pure filesystem model. And I will still be able to make a cheap
copy tag and refer to its HEAD.
/Mats
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Ben Collins-Sussman <su...@collab.net>.
"Mats Nilsson" <ma...@xware.se> writes:
> Greg Stein <gs...@lyra.org> writes:
> > $ svn cp -r 1000 /trunk /module-snaps/rev1000
> > $ svn propedit /modules/mutha
> > (add line:
> > /somelib /module-snaps/rev1000/foo/somelib
> > )
> > $ svn commit /modules/motha
> >
> >
> > IOW, to pin a particular revision for containment within the module, you
> > make a copy to somewhere, and then refer to the (pinned) copy.
> >
> > That is called a "user strategy" and is Badness(tm).
>
> Please set me straight. Why is this considered Badness:
> svn cp -r 1000 /trunk /module-snaps/rev1000
>
> while this is not?
> svn cp -r 1000 /trunk /tags/foobar-1.0
Greg's not saying that using 'svn cp' to create
tags/branches/cheap-copies is a Badness.
He's saying that it's Bad for a module system to *require* that you
make a cheap-copy, so that a particular module can always point to
that location in HEAD.
Instead, a particular module is simply going to point to (revision,
path) pairs. No copies required.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: subversion module system question
Posted by Mats Nilsson <ma...@xware.se>.
Greg Stein <gs...@lyra.org> writes:
> $ svn cp -r 1000 /trunk /module-snaps/rev1000
> $ svn propedit /modules/mutha
> (add line:
> /somelib /module-snaps/rev1000/foo/somelib
> )
> $ svn commit /modules/motha
>
>
> IOW, to pin a particular revision for containment within the module, you
> make a copy to somewhere, and then refer to the (pinned) copy.
>
> That is called a "user strategy" and is Badness(tm).
Please set me straight. Why is this considered Badness:
svn cp -r 1000 /trunk /module-snaps/rev1000
while this is not?
svn cp -r 1000 /trunk /tags/foobar-1.0
/Mats
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Greg Stein <gs...@lyra.org>.
On Tue, May 21, 2002 at 04:31:16PM -0500, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
> > How does a module target a specific revision?
> >
> > 1) copy the rev/path, and include the copy into the module
> > or
> > 2) the module file specifies dir, URL, and revision
>
> The latter :-).
>
> (I'm not actually sure what (1) means...)
$ svn cp -r 1000 /trunk /module-snaps/rev1000
$ svn propedit /modules/mutha
(add line:
/somelib /module-snaps/rev1000/foo/somelib
)
$ svn commit /modules/motha
IOW, to pin a particular revision for containment within the module, you
make a copy to somewhere, and then refer to the (pinned) copy.
That is called a "user strategy" and is Badness(tm).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> How does a module target a specific revision?
>
> 1) copy the rev/path, and include the copy into the module
> or
> 2) the module file specifies dir, URL, and revision
The latter :-).
(I'm not actually sure what (1) means...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Greg Stein <gs...@lyra.org>.
On Tue, May 21, 2002 at 03:49:06PM -0500, Karl Fogel wrote:
> "Hamilton Link" <he...@sandia.gov> writes:
>...
> > 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)
>
> Yes, a module can target a specific revision or it can track head.
How does a module target a specific revision?
1) copy the rev/path, and include the copy into the module
or
2) the module file specifies dir, URL, and revision
I like the latter :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Greg Stein <gs...@lyra.org>.
On Wed, May 22, 2002 at 09:48:29AM -0600, Hamilton Link wrote:
>...
> Yes, thanks; I'm looking forward to pre-alpha. When you say track head
> you mean it can track the head of any branch, right? Probably a stupid
Yup. A branch is just another directory, much like the "trunk" is just
another directory. There is no distinction, as far as Subversion goes.
*Convention* (so far) states that we create /trunk, /tags, and /branches.
But any repository maintainer can set up any other structure they want.
[ for example, I think people maintaining multiple, disparate projects in
the same repos will probably use a *very* different layout ]
> question, never mind. As far as converting the masses goes, any idea how
> many people are interested in SVN?
Everybody that I've ever talked to. I think that as soon as we release 1.0,
we'll see somewhere around 50% of the CVS users in the Open Source community
switching over (helped by things like the ASF, FreeBSD, SourceForge, GNU GCC
comptools, etc; all of them have shown interest in switching; maybe some
pieces of GNOME, too). I think that many of the 50% that haven't switched
will at least be experimenting with SVN within that first year.
Of course, all these numbers are pulled from thin air. But really... many
big repositories are considering the switch. Simply because SVN does so much
better with those big repositories.
I think the Open Source community will switch faster than businesses. Simply
because we're faster to adopt new technology and switch our processes as
needed; businesses usually have a bit of inertia...
> Will there eventually (and maybe I just haven't read enough of the
> Subversion docs) be functionality included in the server that quantifies
> (or even presents graphically) the amount of activity in a module?
If you can define how that is measured, then I could easily see
incorporating such a function into ViewSVN.
> what about built-in viewCVS-like module browsing?
Already being planned. In fact, we're going to extend ViewCVS itself to deal
with both CVS and SVN repositories.
[ need a new name, tho :-) ViewCVS just doesn't sound right for SVN :-) ]
> I guess I'll have to start building and playing with SVN so I can
> recommend it to all my friends.
You bet!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Hamilton Link" <he...@sandia.gov> writes:
> Will there eventually (and maybe I just haven't read enough of the
> Subversion docs) be functionality included in the server that quantifies
> (or even presents graphically) the amount of activity in a module? what
> about built-in viewCVS-like module browsing?
This functionality doesn't exist yet, but it doesn't have to be
included in the server anyway (it could be done on the client, or by a
combination).
> I guess I'll have to start building and playing with SVN so I can
> recommend it to all my friends.
Please do! :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Hamilton Link <he...@sandia.gov>.
Karl Fogel wrote:
>
> Basically, the property does what you want (the property replaces the
> file `mysubmods' in your example). Yes, properties are versioned :-).
>
> Yes, a module can target a specific revision or it can track head.
>
> Does this address your concerns?
>
> -K
Yes, thanks; I'm looking forward to pre-alpha. When you say track head
you mean it can track the head of any branch, right? Probably a stupid
question, never mind. As far as converting the masses goes, any idea how
many people are interested in SVN?
Will there eventually (and maybe I just haven't read enough of the
Subversion docs) be functionality included in the server that quantifies
(or even presents graphically) the amount of activity in a module? what
about built-in viewCVS-like module browsing?
I guess I'll have to start building and playing with SVN so I can
recommend it to all my friends.
h
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion module system question
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Hamilton Link" <he...@sandia.gov> writes:
> 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.
Basically, the property does what you want (the property replaces the
file `mysubmods' in your example). Yes, properties are versioned :-).
> 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)
Yes, a module can target a specific revision or it can track head.
Does this address your concerns?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org