On Apr 4, 2007, at 10:15, Sandberg Per wrote:
> I got a problem wher we got lots of our system in a legacy VC
> system and I want to use SVN as master VC system in the future.
>
> So one solution to do the migration over tim is as i see to make it
> possible to used a mixed system where
> The svn external tag uses a custom protocoll and it is up to the
> user to provide an exectabl that handles that uri som sample:
>
> svn:external
> component_a [CUSTOM]://some_path:and:more:/component_a/rev-1.1
> component_b [CUSTOM]://some_path:and:more:/component_b/rev-1
> component_c [CUSTOM]://some_path:and:more2:/component_c/rev-2.1
>
> And the have svn to do som thing like this:
> CUSTOM "component_a" "//some_path:and:more:/component_a/rev-1.1"
> CUSTOM "component_a" "//some_path:and:more:/component_b/rev-1"
> CUSTOM "component_a" "//some_path:and:mores:/component_c/rev-2.1"
>
> Where CUSTOM is a command in path and the command is spawned for
> each line.
>
> ----------------------------------------------------------------------
> -------------------------------------------
> Is ther anyone that got similar ideas thougths on how to migrate
> slowly and use differnet VC systems at the same time.
The only way I can think of to do that would be to define a new
property for your non-SVN external URLs.
svn propset mycompany:othervcexternals "component_a whatever://server/
path/component_a/rev-1.1" .
Then, write a wrapper script around svn update, and always use that
script instead of directly calling svn update, and this script of
yours would notice and act upon these mycompany:othervcexternals
properties to interact with your other version control system.
This is not great, because what if you want to use a GUI client like
TortoiseSVN? Then you would have to either not use TortoiseSVN's
update feature (and always use the command line client for updates),
or remember to run your othervcexternals fix-up script each time
after updating with TortoiseSVN.
The ickyness of the situation suggests that the best course of action
is to convert everything to Subversion at one time. Set a date. After
that date, shut off access to the old system and import everything
into Subversion. Or, switch the old system to read-only access, in
case you still need access to it.
If that's not possible right away, because people aren't yet
convinced Subversion is the right system for you, then start using
Subversion with one small project which does not require hooks into
any of your existing projects, until you're convinced it's right for
you and you can convert everything over.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 5 07:10:34 2007