ChangeLogs on CVS? Commit netiquette.

[T.V. Raman]

And following up:

Browsed that url, and discovered that I needed to add /trunk to
the bzr url.
But that got me to the next hole, on my Ubuntu Hardy box, the bzr
I have seems to be not new enough --- Ugg!
bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/
bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
16:20:41 retriever bzr-emacs $

aptitude show bzr
Package: bzr
State: installed
Automatically installed: yes
Version: 1.3.1-1ubuntu0.1
Priority: optional
Section: devel
Maintainer: Ubuntu Core Developers <address@hidden>
Uncompressed Size: 15.0M
Depends: libc6 (>= 2.2.5), python (>= 2.4), python (> 2.5) |
         python-celementtree, python (< 2.6), python-central (>= 0.6.5)
Recommends: bzrtools, python-paramiko
Suggests: bzr-gtk, bzr-svn, python-pycurl, xdg-utils
Description: easy to use distributed version control system
 Bazaar is a distributed version control system designed to be easy to use and
 intuitive, able to adapt to many workflows, reliable, and easily extendable.

 Publishing of branches can be done over plain HTTP, that is, no special
 software is needed on the server to host Bazaar branches. Branches can be
 pushed to the server via sftp (which most SSH instalations come with), FTP, or
 over a custom and faster protocol if bzr is installed in the remote end.

 Merging in Bazaar is easy, as the implementation is able to avoid many spurious
 conflicts, deals well with repeated merges between branches, and is able to
 handle modifications to renamed files correctly.

 Bazaar is written in Python, and has a flexible plugin interface which can be
 used to extend its functionality. Many plugins exist, providing useful commands
 (bzrtools), graphical interfaces (bzr-gtk), or native interaction with
 Subversion branches (bzr-svn).

 Install python-paramiko if you are going to push branches to remote hosts with
 sftp, and python-pycurl if you'd like for SSL certificates always to be
 verified.
Homepage: http://bazaar-vcs.org

16:20:26 retriever bzr-emacs $

On 2/18/10, Karl Fogel <address@hidden> wrote:
> "T.V. Raman" <address@hidden> writes:
>>My cvs snapshot of emacs has Changelog files only upto the end of
>>2009 --- has the repository moved, or  are there just no
>>changelogs any more?
>
> Hi, T.V.!  Emacs switched to Bazaar.  Please see
>
>   http://www.emacswiki.org/emacs/BzrForEmacsDevs
>
> and ask any questions here, of course.
>
> Best,
> -Karl
>
>
>>On 2/18/10, Stefan Monnier <address@hidden> wrote:
>>>>> This seems more of a short comming in `bzr log --short' than in the
>>>>> way one writes commit messages.
>>>
>>> Not really: it's the whole idea behing "bzr log --short".
>>>
>>>> We currently *have* policies about ChangeLog entries and commit logs,
>>>> so I agree with Óscar: it is a good practice and we should require
>>>> people to follow it; and treat people who doesn't the same way we
>>>> treat people who mangles ChangeLog entries (that is, a gentle but firm
>>>> reminder that we have guideliness and we're all expected to follow
>>>> them).
>>>
>>> Yes, please, we should require the first line of commit messages to be
>>> an acceptable summary of the whole changeset.
>>>
>>> Could someone update log-edit-mode's font-lock patterns so that the
>>> first line is highlighted specially (at least in the Bzr and Arch
>>> cases)?
>>>
>>> I think log-edit-mode should even go further in this direction.
>>> The buffer should be created as
>>>
>>>   ----------------
>>>   Author:
>>>   Summary:
>>>
>>>   blablabla
>>>   ----------------
>>>
>>> where <blablabla> is the text taken from the ChangeLog.  Then for
>>> backends which support the notion of summary-line, C-c C-c could just
>>> signal an error if the Summary line is still blank.
>>> After that, empty header entries will get removed and the text is passed
>>> as-is to the backend who is then free to pass it as-is to the underlying
>>> VCS or to extract the various fields and do whatever it feels like
>>> with them.
>>>
>>>
>>>         Stefan
>>>
>>>
>>>
>