[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: Ryan Schmidt <subversion-2006q2_at_ryandesign.com>
Date: 2006-06-01 22:16:17 CEST

On Jun 1, 2006, at 19:07, Nick Beadman wrote:

> 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.

It should come as no particular shock to you. If your external says
to use revision 5 of the thing, then it will quite logically do so.
If you have gone into the external's working copy, updated it to HEAD
and committed changes, and now want these to be used in (everybody
else's working copy of) the project, then the external definition
should be updated to reference the new revision number.

Of course you now have to contend with the fact that if you were
pointing at revision 5 of the library before, and now committed a
change and it's revision 42, you should probably see if there were
any changes between 5 and 42 that you didn't want to include.

When I include an external library into a project, I link not to a
revision of the library but to a branch of it. I've decided that
within a branch, I will only make backwards-compatible changes to my
library. If I later want to make a backwards-incompatible change, I
will first make a new branch for that, so that older projects will
not be impacted by the change. Older projects can be updated to use
the library's new branch as necessary by changing their external link
and fixing all usage of the library to match the new conventions.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 1 22:17:47 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.