Ryan Schmidt wrote:
> On Jul 27, 2006, at 22:37, Gabriel Cooper wrote:
>
>> It seems the idea of a "local external" would be beneficial for those
>> that want the benefits of svn externals but want to be kept
>> up-to-date so they're not crippled should that external disappear
>> unexpectedly.
>>
>> One possible implementation would be a hybrid with the Vendor Branch
>> idea: Create a vendor repository then run a "local external" command
>> which imports the off-site directory into the specified local
>> repository /and/ marks the directory as an external. All local
>> projects then reference the local vendor repository as an external
>> and any time one of those local projects is checked out it cycles
>> through the local externals, updates them to the latest code, then
>> exports their data to the working copy. With a simple flag the
>> functionality could override whether it looks for new versions of the
>> external or uses the local repository's code.
>
> I don't understand your proposal. Can you show a set of commands that
> gives a demonstration?
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.
External library:
http://svn.somewhere.com/externalLib
My application (we'll call it "super stuff"):
http://svn.local.com/superstuff
Super Stuff needs externalLib to run. externalLib works out of the box,
I don't need to edit it, but I do /need it/. Just like you said
initially, if their site is down and I need Super Stuff /now/ I'm in a
bind. So. I need a local copy of externalLib. But I want to stay up to
date with it too, just like Externals let me.
I set up a local repository for externalLib so I'll always have it in an
emergency.
http://svn.local.com/vendor/externalLib
I checkout externalLib as a "local external" and dump it into my vendor
directory
(for those just tuning in, this won't work! )
--> svn localcheckout http://svn.somewhere.com/externalLib
http://svn.local.com/vendor/externalLib
At this point if I were to go into the svn server and look at
[svnroot]/vendor/externalLib/db/revs/[revision#] it'd show in the diff
both the externals reference... like so...
PLAIN
K 13
svn:externals
V 53
engines http://svn.somewhere.org/externalLib
... and it would contain the added files being put into the repository
itself (which currently doesn't happen, no local copy of an external is
created)
Then I go into Super Stuff and make it an external:
svn propset svn:externals [...]
then when I check out a new copy of Super Stuff somethinig along the
lines of this would happen:
svn co http://svn.local.com/superstuff
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.
At any rate, enjoy your weekend, I'm off!
Gabriel.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 29 00:31:52 2006