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

Re: Shared source best practices

From: Nick Beadman <nicklist_at_xinet.com>
Date: 2006-06-01 19:07:42 CEST


Thanks for the respose, I am surprised that no-one else jumped in
because this seems to be something that everyone would have to deal

I agree that code in each repository should be developed separately,
and although a top level commit does not effect the svn:externals if
you commit inside that directory then it is committed even though the
svn:externals might specify a revision. On the next check out (at the
top level) then those changes will be lost which is quite a shock.

At this point, I think that I am going to try and patch this up by:

1) Prefixing all svn:externals directories with "EXT_" and having all
common code in that folder and no subfolders
2) Marking all common code with svn:needs-lock to help enforce not
changing things
3) Using the current version of the common code in the projects /
truck and including a shell script in every project to create
releases. The shell script will change the svn:externals properties
to a single revision

Of course, it would be great if Subversion would understand
svn:externals better than as just a pointer to some other repository....


On May 31, 2006, at 11:42 am, Stuart Celarier wrote:

> It seems to me that putting code in separate repositories probably
> means
> that code in each repository should be developed separately,
> regardless
> of how you combine the repositories into working copies using
> svn:externals. After all, you cannot commit a change set contains
> changes to multiple repositories. IIRC, you cannot even commit a
> change
> set that spans an externals definition boundary, even if only on
> repository is involved.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 1 19:09:12 2006

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.