Bill Comisky <bcomisky@pobox.com> writes:
> option 2
> --------
> Use the svn:externals property to handle the multiple checkouts of project
> specific and common code. This has the advantage of everyone being able
> to checkout the entire project structure without having to manually build
> the working copy.
This is the best option, it should work fine for you.
> However, from what I've read, the svn:externals code isn't quite ready.
> Do 'commit'/'status' functions work?
No, but it's not a huge deal either. All this means is that you can't
run 'svn commit' from the very top of your working copy and have the
commit crawl into your 'external' subdirectory. You'll have to go
into the 'external' subdir and commit from there.
But then again, if two projects are sharing a common external module,
the module is a bit like a project in its own right. Most of the time
you'll *want* to make commits to the module independently of the
larger projects, right?
> Another killer is that the revision number of the external is fixed
> to some tag or revision number (using -r), or to HEAD by default.
> Since my common code will frequently be updated from the working
> directory of either project, I'd have to constantly modify the
> svn:external revision number manually (I think).
Huh? I think you're misunderstanding something here.
'svn update' *does* crawl into external subdirs. That means if you
commit a change to the shared module from projectA, you can run 'svn
up' at the top of projectB, and it's copy of the shared module will
still be updated.
There's no need to modify the svn:external value at all. Most of the
time you want to track HEAD, right? I'm not understanding why you
think it needs to change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 29 23:32:08 2003