Ryan,
Thanks for the response! You bring up some very interesting points.
>> 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.
Now that you put it like that, I understand why you would want the
behavior as it is. Of course, Subversion could be friendlier in
helping make sure the external definition is updated but this method
is definitely useful.
> 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.
Of course, but then again you would probably want to pick up those
fixes anyway. At least by doing the update you are making a conscious
decision and therefore can think of the consequences. Most of the
time (at least in my case) the common code is kept backwards-
compatible and I am either fixing bugs, adding more common code or
making it compile with a new environment (Xcode vs. CodeWarrior vs
Visual Studio).
> 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.
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.
Nick
---------------------------------------------------------------------
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:07:40 2006