Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Óscar_Fuentes <address@hidden>

 > > >> >> is not that great. First, building takes a long time.
 > > >> >
 > > >> > Why does the building take a long time in that case?
[...]
 > > The newly created feature branch you are working on is a pristine set
 > > of versioned files on a new directory. If you want to test your change,
 > > you need to build the emacs executable, because it is not there.
 > 
 > Of course.  But building does not take a lot of time, except for the
 > first time, which does a full bootstrap for that branch.

I'm not sure if you are getting it, forgive me if you have: as Óscar
said, people experienced with git, and maybe Mercurial, will tell you
to branch for *every* change.  Why not?  How often do you write a
`let' expression in Lisp? -- a git branch's cost is the equivalent of
a `setq', it's *way* less expensive than a `let'.  But it gives you
the same kind of protection from pollution of the VCS environment that
a let does for a Lisp program, and at the same time allows you to
checkpoint your code, or (if you're so inclined) actually record notes
on what you're doing and why as you go along in the commit logs.  The
argument for branching extremely frequently in git is a no-brainer;
the biggest cost *by far* is keeping track of branch names.

If you do this in git (and in git, I do!), it's painless, because you
have only one workspace for all the small changes.  The branches are
"colocated" in the same repository/workspace; they share a working
tree.  That means that a rebuild is a simple `make', and it's
incremental.  But Bazaar branches *cannot* at present be colocated;
they *cannot* share a working tree.  That means that if you do a
"bzr branch" for a one-line change, you have to do a "make bootstrap"
to test.  EEEEEEeeeeeewwwwww.

 > It's a CVS checkout of the trunk, with local changes.  Each "cvs up"
 > merges the changes on the trunk with my local changes.  Since no one
 > is working on the display engine, I had maybe one or two conflicts in
 > several months.  It's really not such a big deal, even with CVS.  I
 > don't see how any VCS could "shine" in this use-case.  Maybe I'm
 > missing something.

You are.  *You* apparently don't miss having the VCS record your
history as you go along, and that's OK.  But many of the rest of us
*do*, and for your use case + history, a dVCS shines because it's very
cheap to checkpoint your work and record activity and motivation in
the log, as described above.

For your use case, where you don't care about history, you're right;
it's hard to beat CVS by very much.  Until a year from now, when
Yidong comes to you and says, "what were you thinking when you wrote
this code?!" and you are forced to say "I don't know" and you make the
"obvious" fix and 6 months after *that* somebody inserts an Arabic
obscenity into a letter to their mother because it's "I love you"
spelled backwards....

Of course there are other ways to accomplish this kind of history-
keeping, such as comments in the code and entries in the ChangeLog
proper (lord, do I hate merging changelogs!)  Again, if that works for
you, OK.  But I and many others find it useful to have the VCS manage
that task, specifically because unlike a ChangeLog, it provides the
exact patch that goes with the changelog.