Thanks guys, Well, I think that one of the approaches would be to setup the integration server to run only "the features that should pass", and ignore the other ones (using tagging).
@Stephen: Sorry, I used the wrong term. I did not mean partial commit in the technical term, but a "partial feature commit", which is committing a feature that is breaking or not fully working somehow to the main/stable line (and with a comment like "Feature x partially finished). **One good use-case of this, however, is when another developer needs code/artifacts you have wrote and you need to commit, but your commit does not represent the completion of a feature/step/spec.** <-- Here's the use case we are trying to come up with a solution for. I'm using git, actually I love git. However, we started with svn unfortunately and only now the management saw the benefits of git and we migrated. However, 99% of the developers of this project does not know how to use git, and with this I mean they don't know what branches are actually and how they work. The investment of time to teach them this would ruin this project, which is already behind the schedule. So, for now, we are in a "transition phase", using git in a half-***** way, with only the master branch. However, being master the only branch, I think the code there should be stable and have only solid code. Committing partially done or code that might break features would put us in chaos again, and nobody would really look into the CC.rb logs again (since they would fail all the time, as CC.rb is using this master branch too). My co-worder suggested running the whole test suite **only** in staging (we only update staging when all the features are supposedly working) but this would defeat the whole purpose of BDD/Continuous Integration, which must be a support tool in the process and not a specific phase. So, for this specific situation, I thought on other ways we could share unstable code (code that might break tests) without committing to the master branch -- which include patches or even just copy and paste. Or maybe we should just use branches, but won't be easy to convince the management to do this now. Does that make sense? Thanks again, Marcelo. On Thu, Aug 20, 2009 at 9:28 PM, Stephen Eley<sfe...@gmail.com> wrote: > On Thu, Aug 20, 2009 at 8:00 PM, Marcelo de Moraes > Serpa<celose...@gmail.com> wrote: >> >> However, a co-worker of mine came to me and said that partial commits >> are needed to share code. I don't agree with that, I think we can use >> patches or branches to do that (like a development branch) but at >> least one branch should have only stabe/deliverable code. > > First: you keep using that word. I do not think it means what you > think it means. > > You can't really have a "partial commit." Commits are an atomic unit > of version control; you've changed the state of the repository or you > haven't. The *size* of a commit may vary, but a commit that's just > part of everything you're working on is still a commit. And a commit > to a development branch is a commit, too. > > It sounds to me like you're using "commit" not to mean "any update > that alters the history of the repository," but an update to the > official master branch (or trunk, if you're using Subversion). That's > a bit more specialized, and I personally would advise a better word or > phrase for it. "Push to master" works for me. It may be that some of > your confusion with your team may just be a matter of unclear > terminology. > > >> For patches, however, he mentioned that we might have conflicts/code >> duplication, where the guy who shares the patches will have problems >> later on when pulling from the server (he already had part of the code >> that was committed). > > Second: have you tried Git? With all this talk of patch conflicts, > and "the server," and spotlighting development branches like they're a > big deal, I'm guessing you're using Subversion or something else where > branching and merging is a pain. Once I learned to appreciate how > easy branches were in Git, and to use them properly and frequently, a > lot of these sorts of problems just evaporated. (I've heard the same > is true in Mercurial too, FWIW.) > > Get a proper tool that encourages branching and experimentation -- and > then encourage people to branch and experiment. Your policy of having > an "all green" master branch is truly a good one, but if it > discourages people from _using_ the source control on a constant basis > then something needs to be made easier. I personally can't imagine > using Git but refusing to commit my changes to my personal repository > until everything worked. I commit _constantly._ Mostly for the sake > of being able to easily undo stuff. > > > > > -- > Have Fun, > Steve Eley (sfe...@gmail.com) > ESCAPE POD - The Science Fiction Podcast Magazine > http://www.escapepod.org > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
