On 21 Aug 2009, at 16:14, Marcelo de Moraes Serpa wrote:
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).
This is good practice anyway - the @wip thing is a really useful idea
so you can separate regression tests from development feedback tests.
This really means you need to run two builds though - one on the
development branch that might still have @wip hiding in it, and
another one on the 'stable' branch that should not have any @wip left
in it.
@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.
This will not ruin the project - it takes a few minutes to learn,
honestly. Get everyone on the team to read this:
http://blog.hasmanythrough.com/2008/12/18/agile-git-and-the-story-branch-pattern
Then, get them all to install the git_remote_branch gem
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).
You're right here. I think you have two choices: use @wip tags to hide
partially complete scenarios from the build, or use branches. I think
@wip might be better for you as it means you won't have to teach
people how to use branches. However it does leave you with the problem
that people might forget to remove the @wip tags... More on that in a
moment.
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.
What we do at songkick, is maintain a 'staging' branch which we merge
into when we have a green build of the master branch. Our cap tasks
for staging deployment use this branch (I think you have to call it
tag or somesuch in capistrano-speak). You don't have to touch this
branch all that often, and when you do, the merges should be easy
since nobody should really be making changes on the staging branch.
This is the branch which you can run your 'no @wip' build on that will
fail if there are any @wip tags left.
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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
