John Waycott wrote:
>> Perhaps there would be another way entirely to handle keeping the
>> "local external" up to date... perhaps it acts /exactly/ like a
>> normal external /unless/ an error occurs ("svn:propfind request
>> failed on .."). In all other cases it secretly checks the repository
>> versions of "externalLib" and automatically updates the "local
>> external" repository behind the scenes while providing you with your
>> up to date copy, and in the event of error it notifies you of the
>> local copy and uses that.
>>
> As a CM manger, I have to ensure that developers always build with the
> correct software and tools. I'm uncomfortable with the idea of using
> an out-of-date (the local copy) externalLib if the current copy is
> unavailable.
Well... At that point you're either not using any library (*ka-blam!*
you can't build) or you're using the last-known-good. Which resource you
use is up to your particular project. As said in the Vendor Branch
example page at one point they wanted to keep up to the bleeding edge of
an Apache library, and eventually they cut back to releases only.
The proposed solution is to not be dependent on externals not existing.
Presumably if an external isn't accessible for one reason or another,
you'd rather have a working project you can continue using than one that
doesn't build at all. If it were built into subversion itself, then I'd
say the best solution was the one I put at the end of the email (and
quoted above): the "local" external is completely transparent and acts
100% like a normal external does with the only exception being that
should your external be unavailable it asks you whether you want to use
the last used extraction or perhaps gives you options of tags or something.
> A property that specifies a library is from an external source could
> be used to control changes to the local copy so that developers could
> not commit to it directly.
Presumably it would still act like externals do now, wherein (I believe)
you have to commit the external itself directly back to the external
repository. Then on next checkout / update the system would pull your
changes down from the external, save them to the local external, etc.
etc. just like any other change to the library.
If you start wanting to modify the external, simply remove its "local
external" status in the local external's repository then implement the
"Vendor Branch" functionality. Certainly you're not going to be able to
automate keeping a modified branch up to date.
> Once they want to tag a release, all library references must point to
> tags as well to ensure build repeatability.
Hm... I don't know how hard it would be to refer to both a local
external and remote external by way of versions, tags, etc., but it
seems doable, and certainly would be a necessity for releases.
Gabriel.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 31 17:40:51 2006