You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jorge Uriarte <jo...@omelas.net> on 2007/07/03 12:00:58 UTC

Sparse directories and svn:externals

Hi there,

I've been testing the 1.5 preview so we can anticipate the changes needed in
our processes once it's availaible.
At our project we have a *huge* codebase, structured in something like forty
independent modules, that are in turn combined into several
application-bundles (so to call them).
We did deploy (three years ago, now!) a structure that relies heavily in
using svn:externals to bring the proper stable versions of every module into
the different application-bundles.

1.5 brings two features we've been waiting for hungrily: Merge tracking will
allow us to ease the management of each module's own maturity cycle. We
currently merge manually the changes in every module through a three-staged
ladder, and m-t will soon help us on it :-)

The other feature I've started testing is sparse-directories. What I need is
the ability of a given developer to checkout only part of the
application-bundle, so he saves checkout & compilation times, because we
only want to test a part of the applications (mostly vertically architected,
as you can guess)

I'm trying this:

  svn co --depth=immediates http://myurl/svn/myappbundle

but I see that directories inside myappbundles are being checkedout
recursively. Is this the proposed behaviour? I thought directories in
myappbundle would just be created (empty!)-

My other doubt is related to the intended behaviour for "sparse-directories"
regarding externals. Are externals supposed to be allowed? I mean, given
myappbundle holds several directories inside as externals, can I trust on
this feature to select just the externals I want to work with?

Thanks for the time, guys!

_
Jorge
-- 
View this message in context: http://www.nabble.com/Sparse-directories-and-svn%3Aexternals-tf4017828.html#a11410693
Sent from the Subversion Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Sparse directories and svn:externals

Posted by Karl Fogel <kf...@red-bean.com>.
"Jorge Uriarte Aretxaga" <jo...@omelas.net> writes:
> Mmhhh... I can't upgrade the real server, no way. Upgrading our 250K-revision
> repo to 1.4.3 has been a recent enough struggle with the "IT Crowd", and even
> it worked quite good (just some mod_authz_svn tricks), I don't think they
> enjoyed the process at all :-)
>
> I think I'll try to create a testing script against a local svn://
> repo as soon as I get trunk to compile again.

You can use 'svnsync' to mirror the main server into your test
repository, so you're testing with the same data at least.

> The question still remains, though... what's the intended behaviour?
> I'd love to hear that externals are to be slightly upgraded toward
> first-citizen status in svn, but I'm fearing it will no be like that...

No, the svn:externals problems that were there before are still there;
the sparse-directories support is mostly unrelated to svn:externals.

Best,
-Karl

-- 
Subversion support & consulting  <>  http://producingoss.com/consulting.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Sparse directories and svn:externals

Posted by Jorge Uriarte Aretxaga <jo...@omelas.net>.
> > My other doubt is related to the intended behaviour for
> "sparse-directories"
> > regarding externals. Are externals supposed to be allowed? I mean, given
> > myappbundle holds several directories inside as externals, can I trust
> on
> > this feature to select just the externals I want to work with?
>
> I think it will only expand the externals if depth is infinity... But
> I haven't tested that.  If you try it (after server upgrade) can you
> let us know?  Thank you.


Mmhhh... I can't upgrade the real server, no way. Upgrading our
250K-revision repo to 1.4.3 has been a recent enough struggle with the "IT
Crowd", and even it worked quite good (just some mod_authz_svn tricks), I
don't think they enjoyed the process at all :-)

I think I'll try to create a testing script against a local svn:// repo as
soon as I get trunk to compile again.

The question still remains, though... what's the intended behaviour? I'd
love to hear that externals are to be slightly upgraded toward first-citizen
status in svn, but I'm fearing it will no be like that...

Wil report back...

_
Jorge

Re: Sparse directories and svn:externals

Posted by Karl Fogel <kf...@red-bean.com>.
Jorge Uriarte <jo...@omelas.net> writes:
> I'm trying this:
>
>   svn co --depth=immediates http://myurl/svn/myappbundle
>
> but I see that directories inside myappbundles are being checkedout
> recursively. Is this the proposed behaviour? I thought directories in
> myappbundle would just be created (empty!)-

Right now, you'll need to upgrade the server to trunk as well as the
client.  (There is a way to make the client do correct sparse
checkouts even when the server is older and doesn't know about
--depth, but that compatibility code is not fully implemented yet.)

> My other doubt is related to the intended behaviour for "sparse-directories"
> regarding externals. Are externals supposed to be allowed? I mean, given
> myappbundle holds several directories inside as externals, can I trust on
> this feature to select just the externals I want to work with?

I think it will only expand the externals if depth is infinity... But
I haven't tested that.  If you try it (after server upgrade) can you
let us know?  Thank you.

-Karl

-- 
Subversion support & consulting  <>  http://producingoss.com/consulting.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org