Re: [Gnu-arch-users] cscvs?

[Tom Lord]

    > From: David Allouche <address@hidden>

    > On Mon, Dec 08, 2003 at 11:22:09PM +0000, wave++ wrote:
    > > Yet again I've another project to migrate from cvs, but I want to
    > > preserve branches this time because the project used cvs's branching
    > > feature in a fancy way (much like how you use arch in fact):

    > >   - head -> (dead)
    > >     \-- split -> head -> (dead)
    > >                  \-- split -> head -> (dead)
    > >                               \-- split -> head -> (dead)
    > >                                            \-- [CVS got lost here]

    >> Obviously I want to retain full history. I successfully used my own
    >> dirty hack in the past (cvs2arch), but before hacking it futher to
    >> playback branches I was wondering if cscvs does what I need and, if so,
    >> where is the lastest archive :)

    > I am not familiar with the way branches may be used in CVS. From what
    > you say, it seems that you have two branches "head" and "split" and that
    > they are sort of interleaved. Something like

    >   head  -.--o    .--.--o    .--.--o    .-->
    >           \     /    \     /    \     /
    >   split    `->-'      `->-'      `->-'

    > If that is true, for one thing I have a hard time seeing how you can do
    > that in Arch 

What?!  The only problem is that there are so _many_ ways to do it
that I'm not sure we have enough information to pick which one is
best.  I know nothing about how hard it would be to teach cscvs to
convert old cvs history in this way but just to model that pattern in
arch:

One simple one that comes to mind is to start with a version:

        proj--head--1.0

and, when you want to start a split, make:

        proj--split-a--1.0              proj--head--1.0
        
        base-0          ---tag of--->   patch-N

Those can now evolve:

        proj--split-a--1.0              proj--head--1.0
        
        base-0          ---tag of--->   patch-N

        ...     (possible <-> merging)  ...

        patch-i                         patch-T


and when it is time to make "split-a" into the head revision:


        tla get proj--split-a--1.0 wd
        cd wd
        tla set-tree-version proj--head--1.0
        tla sync-tree proj--head--1.0
        tla commit [....]


which will give you:


        proj--split-a--1.0              proj--head--1.0
        
        base-0          ---tag of--->   patch-N

        ...     (possible <-> merging)  ...

        patch-i                         patch-T
              ^
               `_____(same source as)__ patch-S


I don't know if the places where head lines become "dead" constitutes
a milestone but you can also make some tags:


   proj--end-of-life--1.0   proj--head--1.0   proj--start-of-life--1.0

     patch-K  --tag of-->   patch-T
                            patch-S  <--tag of-- patch-X


and, of course, start the new "split":


        proj--split-b--1.0              proj--head--1.0
        
        base-0          ---tag of--->   patch-S


or in terms of the diagram:

             ,----- head always lives on proj--head--1.0
            /
            |   proj--end-of-life--1.0--patch-K tag
            |      |
            |      |   proj--start-of-life--1.0--patch-X tag
            v      |   |
                   v   v
    >   head  -.--o    .--.--o    .--.--o    .--> 
    >           \     /    \     /    \     /
    >   split    `->-'      `->-'      `->-'

                  ^            ^        etc.
                  |            |
        proj--split-a--1.0  proj--split-b--1.0

                (splits live on their own branched
                 versions until they become the head
                 revision)



    > cscvs actually considers the changesets committed to different branches
    > to be part of different streams, or so it seems from my use of it, I
    > have not digged in the changeset construction code. So it would just
    > basically build this:

    >   head  ----------------------->
    > 
    >   split ----------------------->
    > 
    > Unless you have some extra information, for example CVS version tags at
    > branch points, I can hardly see how you can use cscvs to import your
    > project without major changes in the changeset construction logic.
    > But then, when you look at the cscvs code, it clearly asks for being hit
    > in the face, so please do not hesitate :-)


Yeah, I make no claims whether or not cscvs can pick up enough
information to construct the above from what's in your CVS archive
but, anyway, that's one way to represent it in arch.


-t