So now that the SVN may rest in peace, how about to make life simple, everybody will use the git flow diagram (either they use master or develop, either they are advanced developers or simple folks) - it would make life easier if everybody work along the same guidelines.
It is something like: whatever you do, clone and checkout a branch (develop or master), if you want to add your own code, just follow the diagram. If you just work on your own code, doesn't matter - just start a feature and commit locally (or publish and push once in a while if you like a backup)
On Fri, Apr 19, 2013 at 3:36 PM, Daniel Russel drussel@gmail.com wrote:
> > On Apr 19, 2013, at 2:06 PM, Yannick Spill yannick@salilab.org wrote: > > > Le 19/04/13 20:18, Daniel Russel a écrit : > >> On Apr 19, 2013, at 10:35 AM, Ben Webb ben@salilab.org wrote: > >> > >>> On 4/19/13 10:29 AM, Daniel Russel wrote: > >>>> The only issue that is in the release milestone relates to the web > pages. > >>> I would prefer to let the nightly build run first to make sure no > horrible problems have cropped up, then update master from that revision. > Otherwise it would seem that the release hasn't even been tested to compile > everywhere, which is less testing than the nightly builds themselves. > >> Sure. I practice, I think that and what I am suggesting are identical > (in that we will continue to patch the release and there will be plenty of > lag between declaring a version the release and getting everything ready > for people to take). > >> > > If by release you mean a release branch (see first figure of > http://nvie.com/posts/a-successful-git-branching-model/), which implies > to freeze functionality and only correct warnings and bugs, I agree. There > are still warnings in the isd module so I would like to get rid of them > before we commit everything to master. > The original plan, from what I recall, had been to release today, but we > can slip a bit :-) I don't see much reason to wait for things like warning > suppressions are quite reasonable to patch into the master afterwards > anyway and there are an infinite number of such changes that we want to > make. > > > > > Just to be sure: we *are* following the git-flow model as described in > this link, are we? With feature branches, release, hotfix, and develop and > master, right? > At least for feature branches. I haven't end up using git flow release for > the release so far because it didn't play well with having an svn > repository and, since we are feeling things out a bit, I wanted to get a > reasonable IMP state into the master branch sooner rather than at the end. > I don't have much experience with hotfixes yet, so we shall see about > those. They require that you specify the version manually, which is a bit > annoying, but being able to search by tags for point release versions might > be nice. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >