[Systems] [Sugar-devel] g.sl.o issues for Karma and perhaps other activities

Bernie Innocenti bernie at codewiz.org
Sun Jan 3 15:46:04 EST 2010


On Sun, 2010-01-03 at 08:29 +0545, Bryan Berry wrote:

> 
> I am wary of experimenting when the gslo infrastructure is still in
> flux. I would rather stick w/ gitweb or cgit and then move to whatever
> becomes of gslo. Should we start w/ cgit or gitweb?
> 

An alternative to installing a local multi-repository interface just
occurred to me.

To solve the data transfer issue, git offers a pletora of
bandwidth-saving options. One possibility is to let the Nepali
developers clone from each other's repository:


 git clone --reference officemate.local:~bryanwb/src/karma \
    git://git.sugarlabs.org/karma/mainline.git karma


Alternatively, you could rsync the files to your local machine:

  rsync -aP officemate.local:~bryanwb/src/karma/.git karma-ref.git
  git clone --reference karma-ref.git \
      git://git.sugarlabs.org/karma/mainline.git karma

It doesn't matter if the reference repository contains unwanted changes
or hasn't been updated for a while. Any good bits will be reused, and
the rest will be fetched remotely.

Other tips:

 * Never use the http protocol, as it is quite inefficient.

 * try passing the --thin option when you pull. The server-side
   will work harder to minimize file transfers.

 * Another way to speed-up initial cloning is to limit the number
   of revisions with --depth. It's usually not a big deal, unless
   your history contains lots of large files that were subsequently
   deleted.

 * If your history contains plenty of similar files, for example
   PNGs that have been merely moved around, you'd benefit by
   repacking your repository with larger --window and --depth
   parameters. You could repack locally and, when you're happy
   with the result, push it to Gitorious with "git push --mirror".

 * If your history is badly messed up, you may "edit" it locally
   with a combination of the advanced git operations such as
   "git rebase --interactive", "git reset --hard" and
   "git commit --amend". When you publish the resulting edited
   history, people who had previously cloned from you will have
   to refetch. Needless to say, git's arsenal of history-rewriting
   commands is as dangerous as it is powerful.
 
 * the git:// protocol is probably slightly faster than using the
   ssh tunnel. You can easily switch between the two using
   "git remote ..." or by editing .git/config manually.

Free git advice is available from me on #sugar, GMT-5 office hours.
Next business day, on-site support contracts available on demand.
Git is a registered trademark of Stupid Version Control Systems, Inc.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/



More information about the Systems mailing list