[Paraview-developers] Branchmaster OctoPapa and the irrresistable urge to merge

[Biddiscombe, John A.]

David,

OK, two clones locally is one thing I've been playing with, with judicious cut'n'paste activity, things are ok, but it seems like a 'suboptimal' solution.  (I'm not having two builds on the local machine though, instead I'm using the one that does the nightly builds as my 'testspace').

My ideal solution would be to 'commit to topic_x', I understand that this isn't possible with git (as it stands), because when a merge took place it'd need to change the working tree index (and if the merge failed...), the index of the working tree would be knackered, but there must be a large % of cases when commit to branch X would work fine and there are no merge issues, so somehow git ought to be able to manage it. I wonder if this is under development. anyway...

If there are better ways than two trees and two builds, I'd like to know.

JB
PS. you must be working all night in order to reply so fast.

-----Original Message-----
From: Thompson, David C [mailto:dcthomp at sandia.gov] 
Sent: 11 February 2011 10:36
To: Biddiscombe, John A.; paraview-developers at paraview.org
Subject: RE: Branchmaster OctoPapa and the irrresistable urge to merge

Hi John,

I'm not sure my (c) is better than your (a) or (b), but what I've found myself doing recently is keeping 2 clones around: one named devel and one named boogs (sorry for the oblique reference to bugzilla's "zarro boogs found"). And that means 2 build directories. But it does make life easy when I want to commit a fix to master without switching back and forth. I've even been toying with the idea of having boogs do an automatic pull and build via cron while I'm asleep to keep it up to date.

    David 
________________________________________
From: paraview-developers-bounces at paraview.org [paraview-developers-bounces at paraview.org] On Behalf Of Biddiscombe, John A. [biddisco at cscs.ch]
Sent: Friday, February 11, 2011 00:28
To: paraview-developers at paraview.org
Subject: [Paraview-developers] Branchmaster OctoPapa and the irrresistable urge to merge

I have 5 or 6 topic branches locally and I am having a bit of trouble managing the workflow, so since you guys made me use git (which is bloody marvellous, I'm not complaining), I am asking for advice.

Whenever I update from kitware, I do an update of my main master branch (=clean kitware/master) and then do an octopus merge of the 5 topic branches into my working branch. All is fine.

Now I discover a bug or add some new tweak and I need to commit the fix to branch X: the problem comes here
I am in working branch, which is based off kitware/master
git checkout topic X
topic X is based off kitware/master, several weeks ago so when I "git checkout topic X", lots of files in my working dir get touched
commit fix to branch X
git checkout jbworking

Now when I make my project, cmake reruns, tons of files are touched and I spend large portions of my life waiting for things to rebuild when I don't need them to.

It seems I can process in one of two ways
a) Update topic branches whenever I update my kitware master, so that switching to topic X only touches those files on topic branches Y,Z,A,B,C etc, which is a small subset and rebuilds are less painful.
pro : everything up to date, so switching branches should minimize rebuilds
con : I read that we must resist the "urge to merge", because it is bad. I'm not really sure why, so please tell me. Ideally I would rebase each topic branch when I an update from kitware/master to keep things clean, unfortunately, I push these topic branches to our local repo server so rebasing is not allowed.

b) make my fixes in the working branch and commit them to the working branch, then cherry pick them regularly to each topic branch and throw away the working branch whenever I do a kitware update.
pro : Sensible way to approach things and keeps it fairly simple
con : I carry on work most evenings on the laptop and may not be ready to cherry pick fixes to the topic branches and push them. I could pull from the desktop to the laptop, but then I have to maintain another level of synchronization between machines which I guess there's no way to avoid.

Anyway, the internet is too big and I can't read all the blogs about branch management. All of them say to do
a) stash changes, switch branch to topic, commit fixes, switch back - but these people don't work on projects as big as paraview and if you touch vtkObject.h in one topic branch, you're really stuffed because everything gets rebuilt, so I have to go b).

Please tell me what I should do - I am erring towards b). [Until recently, I just had one huge messy branch with everything on and it was a disaster, (it was a git clone of my old personal paraview svn repo), all commits were mixed up together, now I created clean topic branches and want advice].

(I hope there is a 'c' option which simply allows me to commit a fix to branch Y when I'm still on the working branch, but I have not found this yet)

Yours

JB


--
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82

_______________________________________________
Paraview-developers mailing list
Paraview-developers at paraview.org
http://public.kitware.com/mailman/listinfo/paraview-developers