Gabriel Cooper wrote:
>
> I'll give it a go. My svn-fu is low and it's Go-Time(tm) on Friday so
> you'll have to put up with abstracted descriptions.
>
[snip]
> Various scenarios play out here:
> ------- scenario one, external is unavailable --------
> Checking Externals...
> Found Local External 'externalLib'. Checking...
> http://svn.somewhere.com/externalLib is unreachable (500 Server Error),
> Use local copy of 'externalLib' or try again? [(L)ocal/(T)ry again] L
> externalLib will use local repository.
> ------- scenario two, external is up to date --------
> Checking Externals...
> Found Local External 'externalLib'. Checking...
> 'externalLib' is up to date; externalLib will use local repository.
> ------- scenario three, local copy is old --------
> Checking Externals...
> Found Local External 'externalLib'. Checking...
> http://svn.somewhere.com/externalLib has a newer version
> Use local copy of 'externalLib' or update? [(L)ocal/(U)pdate] U
>
> Fetching external item 'externalLib' for local repository
> A [... new versions of files are pulled down... ]
> 'externalLib' is up to date
> ----------------------------------------------------------
> (and then we continue...)
> ----------------------------------------------------------
>
> A superstuff/
> A superstuff/[... Super Stuff's various files are added to your local
> working copy ...]
>
> Fetching local external item 'externalLib' from local repository
> A superstuff/vendor/libs/externalLib/
> A superstuff/vendor/libs/externalLib/[... externalLib's various files
> are added to your local working copy ...]
>
> ----------------------------------------------------------
>
> Hope this on-the-fly example serves to enlighten on the suggestion...
> certainly flags could be presented to avoid the nuisance of user
> input, or perhaps a helpful default might prove the best choice.
> 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. At that point the developer is building the software
incorrectly which can cause problems. In the case where a project
developer and library developer need to collaborate (which is really
where your idea comes to play) you could keep the local copy
synchronized using a separate script.
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. Maybe a pre-commit hook could detect the property
and only allow changes to the vendor portion of the library tree from
the synchronizing script somehow? I hope that makes sense; I would not
want developers modifying the local copy of a library except in a part
of the tree where it explicitly is for that purpose. The last thing you
want is to have two externalLib versions 1.1 that are different.
From a CM perspective, it is important to lay down rules for this sort
of use. We allow developers to externally link to a library's trunk only
during collaborative development. Once they want to tag a release, all
library references must point to tags as well to ensure build
repeatability. You should always know exactly which versions of the
libraries were built for any specific tagged software. My experience is
that failing to do that can really cause problems down the road.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 29 18:30:17 2006