Hello, * Andrzej Szeszo <asze...@gmail.com> [2011-06-23 02:06]: > Latest upstream ips/pkg5 tools need more and more changes to make > them work with OI and illumos. I have asked the version control > system question because I wanted to create a repository for pkg5 > with the changes. > > I wanted to avoid mercurial + mq patch queue solution and started > experimenting with git as I've heard good things about its rebase > feature. > > With some help from hg-git I was able to prepare git repository with > untouched branch which is tracking upstream pkg-gate + branches with > local modifications. I was then able to pull in upstream changes and > rebase customized branches without too much effort. > > Nice rebase functionality, cheap non-permanent branches, ability to > use hg frontend with hg-git extension and also availability of very > good 'Successful Git branching model' document [1] makes Git worth > considering on the backend in my opinion. > > Also, I think model descibed at [1] is worth adopting in terms on > how to organize the repository/branches. It would save us time on > re-inveting repository layout and documenting it for starters. Also, > apparently it proved to be successful for many people. People at > Joyent use this model - they can't be wrong ;) [2] > > By the way - I quite like mercurial. If someone can demonstrate how > to do rebase but using mercurial I'd be willing to try it out. > Thanks in advance!
if I understand it right you want a) lightweight feature branches which are easily removed after merging them into the master branch b) maintain a permanent branch with OI-specific changes and rebase it on top of Oracles upstream branch For a) mercurial offers completely anonymous branches, ie. when you just commit on top of any changeset (this is not really viable with git) or you use the bookmarks extension which allows you to actually label such a branch. Bookmarks can be completely removed after merging a such a branch and thus resemble the behavior of gits branches [1]. For b) mercurial offers the rebase extension which provides equivalent functionality as gits rebase. The question is why we should actually do this for a long-lived named branch rather than explicit merges. Anyway, both workflows (whether they are adequate for our purposes or not) are easily possible with mercurial. [1] There are two caveats with bookmarks, first you always want to ser "track.current = True" so that only the currently active bookmark and not all bookmarks pointing to a changeset get moved forward when you commit on top of it (this brain-dmaged default is gone from mercurial 1.8) and you need mercurial 1.6 to push/pull bookmarks between repos. -- Guido Berhoerster _______________________________________________ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
