Hi Bob,
I appreciate your input and insight here. I will definitely review
and try your recommended steps. I will follow up with my results when
done.
Thanks
Bob Archer wrote:
>> Hi, I have been using CVS since 1998 and I am now finally moving to
>> SVN. After having studied SVN for the last few weeks, getting the
>> server prepared and working with clients, both console and GUI, I
>> think I can use the accumulated experience for a simple migration
>> and
>> new SVN layout.
>>
>> We have had many revisions since 1998 and I don't think its worth
>> the
>> effort to try to re-record all this under SVN. But what I have
>> done
>> is under CVS is checked out l the projects from the last 10
>> revision
>> tags into their own folders by tag name:
>>
>> \rev6_3_452_5
>> \rev6_3_452_6
>> \rev6_3_452_7
>> \rev6_3_452_8
>> \rev6_3_452_9
>> \rev6_3_453_1
>> \rev6_3_453_2
>> \rev6_3_453_3 last official release
>> \rev6_3_453_4 next pending official release
>> \rev6_3_453_5 I would consider this a "branch" w/ one project
>> off
>> 453_3
>>
>> There are at least in total 100+ projects in the total system, but
>> they are not all in each tagged revision, only whats changed for
>> that
>> release. i.e, 453_5 has one project with some exploratory code. It
>> was
>> by mistake (pre-mature) that it was tagged since this code will not
>> be
>> used, but I would like to see how that is applied via SVN branches.
>>
>> I "almost" got the idea of the SVN branch, tags and truck but I am
>> finding myself a little lost which way to go here.
>>
>> I can really use some help here. The above would probably be the
>> simplistic I can make it to go forward and was hoping to see how
>> others would lay it out with the SVN framework. I now SVN offers
>> flexibility and one can move things around later, but what would
>> you
>> suggest here?
>>
>> I decided to post because after I checked out the revision tags, I
>> was
>> wondering if I should do something like:
>>
>> for each revision (upto 453.3)
>> - import revision into trunk
>> - do a "cheap copy" of current trunk into tags
>>
>> with the idea that I would end up with:
>>
>> - branch
>> how do I get that one project 453.5 exploratory code here?
>> - tags
>> \rev6_3_452_5
>> \rev6_3_452_6
>> \rev6_3_452_7
>> \rev6_3_452_8
>> \rev6_3_452_9
>> \rev6_3_453_1
>> \rev6_3_453_2
>> \rev6_3_453_3
>> - trunk
>> \current <---- current would be 453.3
>>
>> and if this the basis for my new SVN layout and then when when I
>> done
>> with 453.4 development I can commit into the trunk and also create
>> a
>> cheap copy into tags "rev6-3_453_4"
>>
>> I speaking as I know what I am doing. :) But maybe I am now. Note,
>> it
>> is critical what we maintain a version numbering like 6.4.453.4
>> (label
>> wise) as that is how the product has worked since 1998. I would not
>> how the SVN revision # only idea would apply yet. I don't use the
>> CVS
>> revision numbers eithers. Only tags.
>>
>> I hope I can get some input here. Thanks.
>
> I would start with your repository empty. Create your trunk / branches /tags in it.
>
> Then I would check-out trunk to a folder.
>
> Once that is checked out I would copy the contents of \rev6_3_452_5 to the working copy folder. Do an
>
> svn add .
>
> then submit
>
> svn ci -m "Initial import of source"
>
> Once I have done this I would create the tag:
>
> svn cp ~/trunk ~/tags/rev6_3_452_5
>
> from there I would copy the contents of \rev3_452_6 into the working copy... then do an svn add. Also do a compare of the files and see if any files in the older rev no longer exist in the newer rev and delete them. Once that is done do your commit and tag.
>
> Keep doing this until you have gotten to the contents of rev6_453_3 into the working copy, hence trunk. Now create your branch:
>
> svn cp ~/trunk ~/branch/rev6_3_453_5
>
> No check out that branch and put the source for _5 into it an commit.
>
> I think that will get you where you want to be, without having multiple copies of your projects in your repository and just using the cheap copies of svn.
>
> Also, this all assumes the procedure of release from trunk with future versions in branches. (Not my favorite way to go.... but many people us it.)
>
> BOb
>
Received on 2011-03-15 09:00:04 CET