On Oct 12, 2007, at 05:43, Giulio Troccoli wrote:
>> 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.
Ok. But I think svn_load_dirs.pl and the layout I proposed would suit
your situation just fine.
Set things up the way I indicated in my last mail. Now, if you need
to make changes to version 2, copy the "2" tag to a "2.x" branch.
svn cp url://to/your/repo/tags/2 url://to/your/repo/branches/2.x
Now you can check out the 2.x branch and make the change and commit
it. Make additional changes as necessary and commit to the branch.
When you're ready for a 2.1 release, you can copy the 2.x branch to a
new 2.1 tag.
svn cp url://to/your/repo/branches/2.x url://to/your/repo/tags/2.1
You can use "svn merge" to get the changes to the other branches, as
necessary. (Make branches for versions 3.x and 4.x as well from the 3
and 4 tags as you need them.)
Alternately, you could have svn_load_dirs.pl copy things into
branches initially, instead of tags, if you don't want any tags of
your initial state, but would rather treat them as branches.
Of course you can set up and use your repository in any way that
makes sense to you. It's just a versioned file system. But it sounds
like you have multiple parallel branches of development, so it might
make sense to put them in a directory "branches".
If having a "trunk" doesn't fit your needs, you can always delete the
trunk after the import process is done, and decree that all
development will take place on branches. No problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 12 13:07:18 2007