Stuart,
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
with.
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....
Nick
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