tracking many cvs/svn/git remote archives

tracking many cvs/svn/git remote archives

[Randal L. Schwartz]

Now that git-cvsimport and git-svn are mature, I'll share my script which I
call "get.cvs" to track a number of remote archives.  It's not extremely
general, but maybe it'll inspire someone else to generalize it.

I have ~/MIRROR/foo-GITSVN tracking a remote archive using git-svn, so
the name of the directory reflects the tracking mechanism.  There's also
*-CVS, *-SVN, *-GIT, and *-GITCVS.

For *-GITCVS, I have to keep the args for git-cvsimport around, so I
store that in the respository under getcvs.gitcvsargs.

For *-GITSVN, I have to force the head/origin to softlink to the proper remote
svn reference.

The *-GIT* merges are safe, because they won't pull over any uncommited
entries, but they *will* merge into whatever the current branch is.  This
keeps any checked out tree trivially up to date, which is mostly what I'm
watching anyway.

Setting up *-GIT* generally requires checking out a master branch to really
track the files... I think I did this with "git-checkout -b master origin".

#!/bin/sh

cd && cd MIRROR || exit 1

case $# in
    0) set -- '*';;
esac

eval set -- "$@"

trap ':' 2
for i in "$@"
do (
        trap - 2
        cd $i || exit
        echo == $i ==
        case $i in
            *-CVS) cvs -q update;;
            *-SVN) svn update;;
            *-GIT*)
                ## first, update "origin":
                case $i in
                    *-GIT)
                        git-fetch
                        ;;
                    *-GITCVS)
                        git-cvsimport -k -i $(git-repo-config getcvs.gitcvsargs)
                        ;;
                    *-GITSVN)
                        ## be sure to have origin "ref: refs/remotes/git-svn"
                        git-svn multi-fetch
                        ;;
                esac
                if git-status | grep -v 'nothing to commit'
                then echo UPDATE SKIPPED
                else
                    if git-pull . origin | egrep -v 'up-to-date'
                    then
                        git log --no-merges ORIG_HEAD.. | git shortlog
                    fi
                fi
                ;;
            *)
                echo "[ignoring]";;
        esac
        )
done


-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

remotes/* for "foreign" archives (was Re: tracking many cvs/svn/git remote archives)

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal>             *-GIT*)
Randal>                 ## first, update "origin":
Randal>                 case $i in
Randal>                     *-GIT)
Randal>                         git-fetch
Randal>                         ;;
Randal>                     *-GITCVS)
Randal>                         git-cvsimport -k -i $(git-repo-config getcvs.gitcvsargs)
Randal>                         ;;
Randal>                     *-GITSVN)
Randal>                         ## be sure to have origin "ref: refs/remotes/git-svn"
Randal>                         git-svn multi-fetch
Randal>                         ;;
Randal>                 esac

It occurred to me after posting this, and while still thinking about the
presentation I'm writing, that it'd be interesting if "get-fetch" could hide
this from me.

If the file in remotes/origin looked something like:

        Pull: !git-svn multi-fetch trunk
        Push: !git-svn commit

then git-fetch and git-push could treat "origin" as a "foreign" branch
and indirect through these commands.

Then I could just use "git-pull" naively, and it would git-fetch origin,
invoking git-svn multi-fetch trunk to update it, and later I could
git-push and it would use git-svn commit.

This idea is half baked, but it could definitely hide the various foreign
adaptors from the invocation line, allowing layered tools to use them
transparently.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

Re: remotes/* for "foreign" archives

[Seth Falcon]

merlyn@stonehenge.com (Randal L. Schwartz) writes:
> It occurred to me after posting this, and while still thinking about the
> presentation I'm writing, that it'd be interesting if "get-fetch" could hide
> this from me.
>
> If the file in remotes/origin looked something like:
>
>         Pull: !git-svn multi-fetch trunk
>         Push: !git-svn commit
>
> then git-fetch and git-push could treat "origin" as a "foreign" branch
> and indirect through these commands.
>
> Then I could just use "git-pull" naively, and it would git-fetch origin,
> invoking git-svn multi-fetch trunk to update it, and later I could
> git-push and it would use git-svn commit.

This sort of integration could be quite cool.  But I think the most
common use of git-svn is with rebase and not pull.  My experience
with git-svn and pull is that I very quickly ended up making broken
commits to svn --- I've had much better luck rebasing.

Re: remotes/* for "foreign" archives

[Randal L. Schwartz]

>>>>> "Seth" == Seth Falcon <sethfalcon@gmail.com> writes:

Seth> This sort of integration could be quite cool.  But I think the most
Seth> common use of git-svn is with rebase and not pull.  My experience
Seth> with git-svn and pull is that I very quickly ended up making broken
Seth> commits to svn --- I've had much better luck rebasing.

Well, you'd still be using "git-fetch origin" then, transparently,
and your push command could do your preferred thing.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

Re: remotes/* for "foreign" archives

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> It occurred to me after posting this, and while still thinking about the
> presentation I'm writing, that it'd be interesting if "get-fetch" could hide
> this from me.

I agree fully, as it was in my earlier "wishlist" ;-)

Anybody?

Re: remotes/* for "foreign" archives

[Petr Baudis]

On Tue, Nov 21, 2006 at 08:33:48PM CET, Junio C Hamano wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
> 
> > It occurred to me after posting this, and while still thinking about the
> > presentation I'm writing, that it'd be interesting if "get-fetch" could hide
> > this from me.
> 
> I agree fully, as it was in my earlier "wishlist" ;-)
> 
> Anybody?

It's currently right after first stage of remotes support in Cogito in
my TODO list (and that's not a vaporware anymore but is actually what
I'm already working on these days).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."