Question about features

[Eric Siegerman]

On Tue, 2009-11-03 at 12:33 +0100, Daniel Carrera wrote:
> Maybe I should just use rsync to send my work to the server for
> testing. Then when everything works I commit...

I think that would help.  Part of the problem is that you're
using your VCS to (among other things) simply copy files around.
You can do that (well, duh -- you *are* doing it), but a VCS
isn't the best tool for the job.

To commit one's work is to make some kind of a statement about it.
The strength of that statement varies greatly by person, by
branch, by project, and indeed by VCS[1].  But it should, IMO, be
stronger than merely "I've finished editing and am ready to test
now", as in your your "edit, commit, push, test, repeat"
workflow.  Basically, "commit" should mean that you believe, in
some sense that's meaningful to you, that the current state of
things is worth preserving for posterity.

In fact, I think you "get" that -- it's why, once the feature is
complete, you want to "take all [your] changes and re-enter them
as a set of nice self-contained commits".  By *not* using BZR
simply to copy files from the machine you edit on to the one you
test on, I believe you'll reduce[2] the need for such cleanup
effort, by generating fewer unworthy-of-preserving commits in the
first place.

> Ah, but that would
> conflict with branches. If I make a separate branch to add another
> feature then rsync wouldn't do the right thing anymore.

How so?  Your test site would bounce around a bit between
mirroring, one after another, the various branches you're working
on, but other than some extra copying effort on rsync's part
whenever you switch focus, so what?  Or am I missing something
here?

The only potential problem I can see would be if you sometimes
edit files directly on the test site.  Bzr would protect you from
clobbering such changes on the next copy from your editing
machine, but rsync wouldn't.  So don't do that -- be scrupulous
about editing *only* on the editing machine.

Of course it's still good to use bzr, not rsync, to push changes
to the production site, after having merged them from the
development branch into trunk.

The workflow I'm suggesting is something like:
  1. edit (in your feature or bug-fix branch on your desktop)
  2. rsync to the test site
  3. test
  4. repeat 1-3 until satisfied with the immediate unit of work
  5. commit
  6. repeat 1-5 until satisfied with the feature as a whole
  7. merge from the feature branch to trunk
  8. possibly rsync trunk to the test site, and test some more
  9. "bzr push" from trunk to production

[1] E.g. "commit" doesn't have to make as strong a statement in a
	developer's private feature branch under a distributed VCS as
	it does either in the project's trunk, or under a centralized
	VCS (where people are usually working directly on the trunk).
	That's because DVCSen decouple the "commit" operation from
	"publish".

[2] Probably not completely eliminate the need for cleanup.
	Still, a significant reduction doesn't hurt.

  - Eric