I've setup 2 permanent and live git-mirrors: one for Pike (called pike) and one for Roxen/Chilimoon/Caudium (called roxen). I.e. they are both synced with the CVS versions at 06:00 every day.
For Pike: git-clone git://git.cuci.nl/pike For Roxen/Chilimoon/Caudium: git-clone git://git.cuci.nl/roxen
Use "git-branch -r" to view all the tracked branches. E.g. "git-log origin/7.6" to view the complete history of the pike 7.6 tree.
As for Pike, I reconnected the source tree beyond what was done in the SVN dump earlier. I.e. all Pike branches now share a common origin and ancestry at Wed Aug 9 10:21:42 1995, the first checkin of ulpc.old.
The repositories are clean and complete, and could be used as an instant master if anyone would like to abandon the CVS repositories. Any suggestions as to possible incorrectness of the repositories are welcome. I'm quite proficient with git and reconnecting history at the moment, so any amendments shouldn't take long.
Some interesting trivia perhaps: the whole source repository, including all history of all Pike versions is about 36MB in size, and for all Roxen revisions the full-history source repository is about 24MB in size, Caudium adds another 13MB.
Incidentally, in trying to sync the old Roxen versions, I got an error in Roxen 1.3, the file /cvs/Roxen/1.3/server/nfonts/32/bell_gothic/bn,v seems to contain a bogus revision number: "unexpected '\x0' reading revision number in RCS file" So that branch is not synced beyond the main developmentline. In order to fix this, either that file needs to be fixed, or deleted (temporarily?) or I'd need a personal copy of the RCS files of 1.3; can any of those options be arranged (mast/grubba?)?
P.S. It is, of course, possible to create a "roxen" git without either Roxen or Caudium; but since it (at best) saves you 24MB or 13MB in space, it's not really a big problem. If one should insist, removing the offending tags from the repository, then repacking it, will shrink the size.
P.P.S. If anyone wonders why the original git archive is smaller than what you find on your own disk after cloning my versions, that's because you didn't try running "git-repack -d -a -f --window=100" yet.
On Mon, Feb 25, 2008 at 01:26:23AM +0100, Stephen R. van den Berg wrote:
I've setup 2 permanent and live git-mirrors: one for Pike (called pike) and one for Roxen/Chilimoon/Caudium (called roxen).
wow, that's great, thank you!
As for Pike, I reconnected the source tree beyond what was done in the SVN dump earlier. I.e. all Pike branches now share a common origin and ancestry at Wed Aug 9 10:21:42 1995, the first checkin of ulpc.old.
nice!
have you tried cvsexportcommit to commit changes back to the original pike cvs repo?
greetings, martin.
Martin B?hr wrote:
have you tried cvsexportcommit to commit changes back to the original pike cvs repo?
No, not yet. First I need to have something to actually commit. However, given the fact that the cvsexport basically applies the diff to a checkedout CVS-tree, and then uses CVS itself to perform the commit; I don't foresee large problems with that.
Incidentally, what I forgot to mention earlier was that: - All Roxen/Caudium/Chilimoon branches share a common ancestry (of course?). - In order to get the repository as small as mine, you merely need to run "git-gc" (and not (necessarily) git-repack as mentioned earlier).
For people new to git, what you usually do is something like the following:
apt-get install git-core git-clone git://git.cuci.nl/pike cd pike git-branch 7.7 origin/7.7 git-branch 7.6 origin/7.6 git-branch 7.4 origin/7.4 git-checkout 7.7 git-branch -f master 7.7 git-checkout -f master
Now you are ready to create your own changes on top of 7.7 in your own development branch called master.
git-log master git-log 7.7 git-log 7.6 git-log 7.4
After making changes, use:
git-commit -a -m "Some useful one-line-description"
and repeat as often as needed (of course).
In order to update the mirror from upstream (my repository, where you cloned from), simply run:
git-fetch
Every once in a while. After doing so, perform:
git-rebase
to actually move forward your own "master"-branch changes so they are automatically merged and (re)based onto the latest (official) updates from 7.7 Pushing back the changes into the official release involves using CVS (externally from git) still. The native git mechanisms cannot be used for that until the official repository is also changed to git.
The nice thing about git is that merges from the developmentbranch back into older stable branches are seemless and fully annotated. These advantages however, cannot be used until git is used natively. In theory, the merges could be retro-fitted into the branches, but there currently is no automated way of doing that to the existing tree (it can be done manually, git allows all kinds of "afterward fixing").
pike-devel@lists.lysator.liu.se
-
Martin Bähr -
Stephen R. van den Berg