>
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
-----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
> Sent: 10 October 2007 10:41
> To: Giulio Troccoli
> Cc: users@subversion.tigris.org
> Subject: Re: Migration to SVN
>
> On Oct 8, 2007, at 04:03, Giulio Troccoli wrote:
>
> >> On Oct 5, 2007, at 06:25, Giulio Troccoli wrote:
> >>
> >>> I am working on a big project to migrate our source code from an
old
> >>> system (CMS running on VMS OS) to Subversion. As far as I know
> >>> there are
> >>> no tools on the like of cvs2svn that I can use (but if I'm wrong
> >>> let me
> >>> know please). So the migration has to be done manually.
> >>>
> >>> For legal reasons we support not only the latest version of our
> >>> product
> >>> but some older ones too, i.e. if a bug if found in, let's say,
> >>> version 2
> >>> then it will be fixed in version 2, 3 and 4 (given 4 is the
latest).
> >>> Therefore we need to keep a source tree for each supported
> >>> version. What
> >>> did, in CMS, and will, in SVN, happen is that a change in a file
in
> >>> version 2 is automatically merged into version 3 and 4. When
> >>> version 5
> >>> is released, the source for version 4 is copied to version 5. I
> >>> don't
> >>> know whether it's a cheap copy or not in CMS but I don't care.
> >>> All this
> >>> to say that there is a link between each version as one is,
> >>> originally,
> >>> a copy of the previous.
> >>>
> >>> What I am planning to do is the following (supposing we support
> >>> version
> >>> 1, 2, 3 and 4):
> >>> - version 1 will be imported exactly as extracted from CMS
> >>> - version 2 will be committed as if it was a massive change fix.
> >>> To do
> >>> this I plan to make a cheap copy of version 2 and then replace
> >>> everything with what extracted from CMS. But, in version 2 I
> >>> might have
> >>> new files/directories been added as well as old files/directories
> >>> been
> >>> deleted. I'm planning to use svn add and svn delete to fix this
> >>> situation and then commit the changes.
> >>> - repeat the same steps for version 3 and 4
> >>>
> >>> Doing the migration this way I will save a lot of disk space and
> >>> will
> >>> retain the logical link between versions.
> >>>
> >>> Does anybody see any potential danger in this procedure? Has
> >>> anybody any suggestions on how to improve the migration?
> >>
> >> Sounds like a good plan. You can use the svn_load_dirs.pl script to
> >> automate the process of importing versions 2, 3, and 4 while
handling
> >> the adds and deletes. See the book for more information.
> >>
> >> http://svnbook.red-bean.com/en/1.4/
> >> svn.advanced.vendorbr.html#svn.advanced.vendorbr.svn_load_dirs
> >
> > Thanks for the tip. I thought about using svn_load_dirs.pl but I
> > wasn't
> > sure it was the right tool. I will do some testing though. Hopefully
> > everything will be fine and I will have a much better life :-)
>
> I have myself used svn_load_dirs.pl to import an old project of mine
> into Subversion. It worked great.
>
> > However, I noticed that the parameters to be passed to the Perl
script
> > cannot be a relative path, i.e. cannot contain the '..'.
> >
> > Keeping the example of my original email, the structure of the
> > repository will be something like
> >
> > repo
> > |_1
> > | |_test
> > | |_src
> > |_2
> > | |_test
> > | |_src
> > |_3
> > | |_test
> > | |_src
> > |_4
> > |_test
> > |_src
> >
> > I don't know how to use the svn_load_dirs.pl then because I would do
> > something like
> >
> > svn_load_dirs.pl \
> > http://localhost/repo/1/test/src \
> > ../../2/test/src \
> > <local dir with version 2>
> >
> > but I can't. Any suggestions on how I could use the script anyway?
>
> I'd suggest a slight change to your proposed repository structure:
> add a directory which always contains the latest code. In the Vendor
> Branches chapter of the book this is called "current" but since this
> is software you are yourself developing, and not software imported
> from a vendor, you should call it "trunk" as the rest of the
> Subversion book does. Your directories 1, 2, 3 and 4 are then tags of
> that trunk at particular points in time. Later, you can create more
> tags as the need arises.
>
> The structure would be:
>
> repo
> trunk
> test
> src
> branches
> tags
> 1
> test
> src
> 2
> test
> src
> 3
> test
> src
> 4
> test
> src
>
> First, import your initial version ("1") into trunk using "svn
import".
>
> svn import /path/to/local-dir-of-1 url://to/your/repo/trunk
>
> Then create the directories branches and tags using "svn mkdir".
>
> svn mkdir url://to/your/repo/branches
> svn mkdir url://to/your/repo/tags
>
> Copy the trunk to tags/1 using "svn cp".
>
> svn cp url://to/your/repo/trunk url://to/your/repo/tags/1
>
> Now use svn_load_dirs.pl to quickly load versions 2, 3, and 4 into
> the trunk and copy them to their respective tags:
>
> svn_load_dirs.pl -t tags/2 url://to/your/repo trunk /path/to/local-
> dir-of-2
> svn_load_dirs.pl -t tags/3 url://to/your/repo trunk /path/to/local-
> dir-of-3
> svn_load_dirs.pl -t tags/4 url://to/your/repo trunk /path/to/local-
> dir-of-4
>
> Now you can continue your work on trunk as per usual, and you can
> copy the trunk to a new branch or tag whenever you feel like it.
>
>
Sorry it took me a little to reply.
Your proposed layout would be fine if we supported only the latest
version (i.e. 4). But we do not. We do have to fix bugs in, let's say,
version 2 and propagate it in version 3 and 4 too. In this case
customers on version 2 will not upgrade to version 4 but will get
version 2.1 (or something like that). My point is that development does
not happen on trunk only, but in fact the 'test' directory I mentioned
are sort of trunks for each version (we also have another directory
where we promote the code that is ready to be tested, I know, very
confusing).
To me it looks like svn_load_dirs has been design with the "standard"
layout in mind (the one you proposed basically) which does not suit my
process. I don't think I will use the script, I find that two simple
commands to get the unversioned and missing files and add or delete them
gives me what I want in a pretty simple way.
Thanks a lot for your help anyway.
Giulio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 12 12:43:28 2007