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