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