OpenCSW source in git

two possibilities exist, (1) keep a repository with submodules, and (2) create one big repository containing all recipies.

Migrating to git, TODO

two areas need to be considered, migrating gar, and migrating the package recipies.

Migration of gar

  • remove the svn:external references to gar from the pkg/XX/trunk's
  • optional: add symbolic links to gar and check in
  • remove creation of svn:external from gmake newpkg

Migration of pkg recipies

  • The _REVISION function in gar.pkg.mk would need to be altered to use a sha1 instead of a svn revision id when generating package file names.
  • The _REVISION function in gar.pkg.mk would need to be altered to use git to check for clean vs dirty working tree.
  • The _REVISION function in gar.pkg.mk would need to be altered to ensure the sha1 of the committed tree was also available in origin/master (ensuring public visibility of the commit)

advantates / disadvantes of full or submodule style

with submodules its easier to convert one by one. the repository can be checked out, and only the submodules needed can be initialized in the working copy. its much speedier. but, one pays a price. git's submodule interface has some potential to improve so to say.

comparison on login.opencsw.org, user home directory, full repository

  • check out of "pkg" from subversion takes 15 minutes
  • clone of full "pkg" repository from git takes 5 minutes
  • update of "pkg" from subversion with no changes takes more than a minute
  • update of "pkg" from git with no changes takes seconds

git vs. mercurial (hg)

Both have approximately the same functionality. While git favours a little more "the clean changeset" and allows better editing of changesets, hg slightly simpler to use in general but tries to keep the changesets stable. Git is C based, and quite complex. Mercurial is python based, slim, supports plugins and is simpler to code, port and fix/extend.

Currently more people at OpenCSW know git. Therefor we started with git. Also the Github user interface seems better than BitBucket, and the speed is much better than that of google code. Google code has much bigger space allowance though.

DVCS in brief

Distributed version control systems like GIT, Mercurial allow to clone the whole repository into your personal workspace. Beside speed, merge tracking, history editing, and rebasing commits onto the newest development line belongs to their core functionality. Backup becomes neglectible as the repository is cloned to multiple places.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License