On Jun 2, 2006, at 20:05, Nick Beadman wrote:
>> 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.
>
> This is an interesting idea, but by allowing yourself to make any
> change to the common code you are making it impossible to build an
> older release of a product exactly as it was when shipped. Although
> given that you are only likely to building an older release to make
> a fix, it may be acceptable to pick up new common code as the
> product will be tested before the fix is released.
>
> In fact I hadn't given any thought to using branches for common
> code usage and it is possible to create a branch in the common code
> for each product and version which would give you the ability to
> get the code back exactly as shipped. Of course, this would mean
> many branches and the common code base would probably become unwieldy.
True -- I can't go back exactly to a released state this way. (We
haven't needed to do this yet.) If that's paramount, then combining
the branch with a revision is an idea, or you could tag the branch at
each relevant stage, and link to the tagged library in the external
definition. I think that would be a perfectly reasonable use of tags,
and shouldn't be any more unweildy than tags in any other project.
> I think I am going to go ahead and use revision-less external
> definitions for project trunks and then use scripting so that when
> a release is branched the external definition is converted to one
> that specifies a revision.
I believe that's exactly what the svncopy perl script does, though I
haven't used it myself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 2 20:21:06 2006