[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Modeling recursive CVS modules in subversion-1.0.x

From: Brad Spencer <spencer_at_infointeractive.com>
Date: 2004-04-23 02:44:55 CEST

On Mon, Mar 29, 2004 at 06:21:27PM -0400, spencer wrote:
> We have a lot of smallish libraries within one repository. There are
> dependencies between these libraries in the sense that some higher
> level library needs one or more lower-level libraries checked out in
> order to build. Right now, we model these dependencies with the CVS
> modules file. For example, consider the following libraries (one per
> 'lib*' directory):

I while back, I posted the message I'm replying to, available as

Later, I chatted with Ben Collins-Sussman about svm:externals and the
like some more. Here are some snippets of this, which I'm sure he
won't mind since it was in the public #svn channel.

<sussman> if you run 'svn up' from the top of your wc, it will update
          everything, following the svn:externals list
<sussman> commits won't, and that's an acknowledged bug.
<sussman> it means you'll have to commit a few times.

Except in my case "a few times" is more like "fifty or a hundred". :(

<spencer_> well, if I'm on a branch, then the externals will all point
           to the trunk via the absolute URLs
<sussman> spencer_: when you copy /trunk to /branches/foo
<sussman> you'll need to change all the externals properties in the
<sussman> to point to dirs in the branch
<sussman> it's a bit awkward, admittedly.

Upon reflection, too awkward, I'm afraid :(

<spencer_> how do i cleanly add to a current checkout... like the
           equiv of "cvs update -d subdir"...
<sussman> there's no way to do that.
<sussman> well, it's a bug, at least.
<sussman> if you do a nonrecursive checkout, then try to 'update' a
          missing dir, it doesn't work currently.
<sussman> basically, any use of --nonrecursive is busted.

The equivalent of "cvs update -d subdir" would allow us to simulate it
outside of svn. We could maintain version control on the "module"
relationships by storing the relationship list in svn, just like the
CVS modules file.

<spencer_> no prob really... bugs are better than "not designed that
           way" because we are not talking immediate term
<spencer_> we are just starting to plan this

I've also noticed similarities in issues #1336 and, to a lesser
extent, #1167. Are these the issues I should be following in order to
know if/when svn will be feasible for our repository? Thanks for your

Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 23 02:46:01 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.