On Thu, Mar 25, 2010 at 2:28 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, 25 Mar 2010, Kai Germaschewski wrote:<br>
<br>
> On Thu, Mar 25, 2010 at 12:00 PM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>> wrote:<br>
><br>
> > On 25 March 2010 01:14, Kai Germaschewski <<a href="mailto:kai.germaschewski@unh.edu">kai.germaschewski@unh.edu</a>><br>
> > wrote:<br>
> > > Fine with me (I'm the one who introduced it originally).<br>
> > ><br>
> > > My off-topic 2 cents: I hate reply-to headers.<br>
> > ><br>
> ><br>
> > BTW, I think this is an example of bad usage of mercurial branches...<br>
> > You should use a separate clone for these kind of tasks. Mercurial<br>
> > branches would make more sense for release versus development,<br>
> > although even PETSc does not uses this model. IMHO, creating a branch,<br>
> > push some fixes, merge back to default, and close branch is just<br>
> > repository pollution.<br>
> ><br>
><br>
> I actually disagree on this. The ts-fixes branch was a separate clone in the<br>
> beginning, actually. I did go through the efforts of separating this into a<br>
> sequence of patches, instead of having one "this one patch fixes all<br>
> approach", and whereas maybe for that particular case it could be considered<br>
> overkill, in general I consider it highly useful to break up changes into<br>
> pieces that can actually be verified by looking at them.<br>
<br>
</div>agree to this.<br>
<div class="im"><br>
> So the way I see it, there are basically three ways to merge a change like<br>
> this (or any which is a sequence of patches) into the main repo:<br>
><br>
> 1) do them in a separate branch, then merge that branch (and close the<br>
> branch, which I didn't but should have (mercurial used to not even support<br>
> this, a major shortcoming...)<br>
> 2) do them as a sequence on the top of head directly. Unfortunately, that<br>
> goes wrong if someone else changes head while working on the sequence of<br>
> patches. In that case, you end up with two branches which will merge with a<br>
> merge changeset. That's effectively the same thing as 1), branching and<br>
> joining, except that the branch doesn't have an explicit name, but I don't<br>
> really see the difference. If you guys don't like the explicit naming, I can<br>
> certainly adapt to that...<br>
<br>
</div>generally in-repo-branch and a clone should have similar workflow and<br>
features. the eqivalent of the 'branch-name' for a clone is the 'clone-url'.<br>
<br>
For eg: for petsc-dev use use <a href="http://petsc.cs.iit.edu/petsc/petsc-dev" target="_blank">http://petsc.cs.iit.edu/petsc/petsc-dev</a>, and for<br>
petsc-3.1 its <a href="http://petsc.cs.iit.edu/petsc/petsc-release-3.1" target="_blank">http://petsc.cs.iit.edu/petsc/petsc-release-3.1</a><br>
<br>
[whereas if this were implemented as repo-branch - there would be a<br>
branch-tag]<br>
<br>
So one can do either in-repo branches or clone branches [with similar<br>
workflow] - so I prefer clone branches.<br>
<div class="im"><br>
> 3) Just import the patch (with some manual trickery) into head as a single<br>
> changeset -- for obvious reasons, I don't think this is a good way, and<br>
> history is lost.<br>
<br>
</div>Yes this is not good.<br>
<div class="im"><br>
><br>
> Both 1) and 2) have the disadvantage of introducing potentially lots of<br>
> merge changesets if development goes on for a while while head moves, too,<br>
> and one keeps the branch in sync. git handles this case by doing a "rebase"<br>
> instead of "merge" which keeps one's development clean (but one needs to be<br>
> careful with distributing things along the way, as history gets rewritten.)<br>
<br>
</div>Hg also has rebase. With clone repos - one has to be careful as to do<br>
this only with local/unshared changeset. Perhaps this works with<br>
in-branch clones aswell [I've never explored]<br>
<div class="im"><br>
><br>
> Anyway, this probably shouldn't lead to a git vs hg discussion, but I've<br>
> used mercurial as my main tool for various things for quite a while, and<br>
> recently learned more about git, and for me it solves a lot of the annoying<br>
> little things I kept running into with hg. Including having a gui that let's<br>
> you go through changes before commiting them, and separating them, so you<br>
> don't need to do "can't remember what the heck I changed -- I wish mercurial<br>
> had a frontend like bk" commits.<br>
<br>
</div>I use 'qct' for this. Perhaps its not as feature rich as it should be<br>
- but its decent. [it supports git and other tools aswell]<br>
<div class="im"><br>
> (By the way, even for hg there's "hg diff" and "hg diff | diffstat"<br>
> which helps...) I used to work on the linux kernel with bk, so it's<br>
> probably no surprise that git seems to support the kind of workflow<br>
> I'm used to, though...<br>
<br>
</div>One thing hg lacks is the 'bk revtool' - where its easy to browse<br>
history. Yeah one can browse history on the web interface - but its<br>
not as good as the revtool.</blockquote><div><br></div><div>The Murky tool on the Mac can do all this stuff. Sean and I</div><div>are going to start developing it.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Satish</font></blockquote></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>