RE: svn:externals

Hello,
Below is an idea from my previous email. Instead of using post hook, I has the script do the job.

It is not a big issue if SVN doesn't support taking a snap including external modules in nature.
A script below should work:
(1) get the external property
(2) Modify the property of externals with the tag. eg: http://test/lib1 to http//test/lib1/tags/rel_1
(3) svn copy the root module and external module to the corresponding directory based on the project layout.
      all the modules then will have the same TAG.
(4) revert the property of externals
Now: svn co tagged_revision_path should check out the tagged copy for all modules directly.
The only rule is that all people using the SVN should put the tagged version to the specified place and they should
always use the script to TAG/Branch. It should be feasible as a rule for all the designers.
It is superb if such kind of feature is supported by SVN in nature. An option in svn copy to tell the project layout should
work.

But till now, I am afraid you cannot switch from CVS to SVN in your case. SVN doesn't run status/commit on external
modules when you issue the command under the root module. There is no easy way to work around.
IMHO, svn:externals is really an important feature to defeat CVS. It is the only hurdle before me when switching from
CVS to SVN.

I am waiting for it to be fixed. I have just checked the issues in 0.23. They are working on it now. Cheers!
http://subversion.tigris.org/issues/show_bug.cgi?id=1167

regards,
Yanghui Bian

-----Original Message-----
From: Ben Gollmer [mailto:ben@jatosoft.com]
Sent: Friday, April 25, 2003 00:04
To: SteveKing
Cc: Subversion Dev
Subject: Re: svn:externals

On Thu, 24 Apr 2003 15:37:32 -0500, SteveKing <steveking@gmx.ch> wrote:
> > Instead of trying to automatically load your libraries in
> > "svn:external", how about linking specific tagged versions?
>
> That's not what we need. We have one project (a library) which
> is used from several other projects. This library evolves with
> those other projects. So during development on the projects
> themselves the library also changes. And the changes to the
> library get committed with every commit to the project.

My quick thoughts on this problem: The simple (relatively speaking) solution
seems to be a hook in svn copy that will look at the svn:externals property on
the directory being copied, check the revision # of each external lib, then fix
up the svn:externals property to include the revision number before committing.

Of course, there could be a switch to turn this automatic update on/off, in case
you wanted your copy to continue tracking the trunk of the external lib(s).

This isn't exactly the same as CVS - as Ben Collins-Sussman brought up on IRC,
it doesn't quite work out for branches. CVS users would expect external libs to
automatically branch when they create a main project branch.

If you are using your copy as a tag, however, it works out fine. Personally,
since I have very little prior experience with CVS, I wouldn't expect automatic
branching of external libs anyway.

Thoughts? Would libsvn_client/copy.c be the place to implement this?

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