emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bzr repository ready?


From: Óscar Fuentes
Subject: Re: bzr repository ready?
Date: Sun, 22 Nov 2009 07:11:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

[snip]

>> 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....
>
> A VCS is no panacea from bugs.

It is no panacea, but helps a lot.

Suppose that some user files a bug report saying: "that piece of elisp
code used to work fine until I upgraded to version 23.3 from 22.4." You
check that the elisp code is correct and that it fails to produce the
right result. Now, if you were able to pinpoint the exact commit where
the bug was introduced, it is quite likely that that knowledge will give
you a lot of insight on the problem.

Having a VCS allows you to do a binary search on the project history for
the buggy commit. With CVS it is a bit tricky, but with
changeset-oriented VCSs like bazaar or any other modern VCS it is
trivial. If you have local access to the project history (the case of
Bazaar, git, mercurial... but not Subversion, for instance) the process
can be very fast. Those DVCSs even have a specific command for doing the
work (in the case of Bazaar, it is a plugin that you install
separately). You write a test case and ask the VCS to test it among two
points on the project history and report what's the first revision that
makes it fail.

BTW, one thing that the people who only have experience with CVS does
not appreciate, is a changeset-oriented VCS, where the source base
transforms on discrete and well defined steps. Among other things, this
makes the Changelog unnecessary, as it turns to be the equivalent of
`bzr log'. It is necessary to fix some old habits, though. Every commit
should be a complete, consistent and unique change: a bug fix, a new
feature, some code cleanup, etc. But no more splitting a logical change
among several commits or mixing unrelated changes on the same commit.

> I'm fine with that, I just said that I don't see how a VCS can "shine"
> in my case.

Of course I didn't know your specific case when I said that a DVCS is a
"shining" tool for you. I hope, however, that after some time you will
realize that it can dramatically improve the productivity gain one gets
from using a VCS, when you come from VCS.

-- 
Óscar





reply via email to

[Prev in Thread] Current Thread [Next in Thread]