ChangeLogs on CVS? Commit netiquette.

ChangeLogs on CVS? Commit netiquette.

[T.V. Raman]

Friends,

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?

On 2/18/10, Stefan Monnier <monnier@iro.umontreal.ca> 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
>
>
>

Re: ChangeLogs on CVS? Commit netiquette.

[Karl Fogel]

"T.V. Raman" <tv.raman.tv@gmail.com> 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 <monnier@iro.umontreal.ca> 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
>>
>>
>>

ChangeLogs on CVS? Commit netiquette.

[T.V. Raman]

I did first check
https://savannah.gnu.org/bzr/?group=emacs
since I remembered that the bzr swwitch had been discussed.
Following the instructions there, I had earlier tried (and just
repeated)
the command given, and it bombs:

bzr branch http://bzr.savannah.gnu.org/r/emacs
bzr: ERROR: Not a branch: "http://bzr.savannah.gnu.org/r/emacs/.bzr/branch/".
16:16:45 retriever bzr-emacs $

On 2/18/10, Karl Fogel <kfogel@red-bean.com> wrote:
> "T.V. Raman" <tv.raman.tv@gmail.com> 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 <monnier@iro.umontreal.ca> 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
>>>
>>>
>>>
>

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 <ubuntu-devel-discuss@lists.ubuntu.com>
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 <kfogel@red-bean.com> wrote:
> "T.V. Raman" <tv.raman.tv@gmail.com> 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 <monnier@iro.umontreal.ca> 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
>>>
>>>
>>>
>

Re: ChangeLogs on CVS? Commit netiquette.

[Óscar Fuentes]

"T.V. Raman" <tv.raman.tv@gmail.com> writes:

> 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 $

You can install a modern version of bazaar from the bzr ppa:

https://launchpad.net/~bzr/+archive/ppa

Everything since Ubuntu Dapper is supported.

ChangeLogs on CVS? Commit netiquette.

[T.V. Raman]

I browsed through launchpad, and went away screaming with
confusion; finally built bzr 2 from source.

-- 
Best Regards,
--raman


Email			:  raman@users.sf.net :〒
WWW			:    http://emacspeak.sf.net/raman/ : ♁
       GTalk		: tv.raman.tv@gmail.com : ☏
PGP			:    http://emacspeak.sf.net/raman/raman-almaden.asc : ⌨
Google			: tv+raman  :  ?
IRC			:    irc://irc.freenode.net/#emacs : ☢
BRL:	⠠⠞⠲⠀⠠⠧⠲⠀⠠⠗⠁⠍⠁⠝	: ☠


On 2/18/10, Óscar Fuentes <ofv@wanadoo.es> wrote:
> "T.V. Raman" <tv.raman.tv@gmail.com> writes:
>
>> 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 $
>
> You can install a modern version of bazaar from the bzr ppa:
>
> https://launchpad.net/~bzr/+archive/ppa
>
> Everything since Ubuntu Dapper is supported.
>

ChangeLogs on CVS? Commit netiquette.

[T.V. Raman]

And after building bzr from source 2.0 on ubuntu jaunty -- bzr
branch segfaults in python 2.6 after pulling about 17mb in trunk.

-- 
Best Regards,
--raman


Email			:  raman@users.sf.net :〒
WWW			:    http://emacspeak.sf.net/raman/ : ♁
       GTalk		: tv.raman.tv@gmail.com : ☏
PGP			:    http://emacspeak.sf.net/raman/raman-almaden.asc : ⌨
Google			: tv+raman  :  ?
IRC			:    irc://irc.freenode.net/#emacs : ☢
BRL:	⠠⠞⠲⠀⠠⠧⠲⠀⠠⠗⠁⠍⠁⠝	: ☠


On 2/18/10, Óscar Fuentes <ofv@wanadoo.es> wrote:
> "T.V. Raman" <tv.raman.tv@gmail.com> writes:
>
>> 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 $
>
> You can install a modern version of bazaar from the bzr ppa:
>
> https://launchpad.net/~bzr/+archive/ppa
>
> Everything since Ubuntu Dapper is supported.
>

Re: ChangeLogs on CVS? Commit netiquette.

[Karl Fogel]

"T.V. Raman" <tv.raman.tv@gmail.com> writes:
>And after building bzr from source 2.0 on ubuntu jaunty -- bzr
>branch segfaults in python 2.6 after pulling about 17mb in trunk.

That's bad (and rather unusual, as far as I know).

Hmm. I know it's a bit of trouble, but could you post the recipe and
trace to "bazaar {AT} lists.ubuntu.com"?  I think they'd like to know
about this, and can probably help you.

I'm sorry it's proving so much trouble to get the latest Emacs :-(.

-Karl

Re: ChangeLogs on CVS? Commit netiquette.

[Jan Djärv]

Karl Fogel skrev:
> "T.V. Raman" <tv.raman.tv@gmail.com> writes:
>> And after building bzr from source 2.0 on ubuntu jaunty -- bzr
>> branch segfaults in python 2.6 after pulling about 17mb in trunk.
> 
> That's bad (and rather unusual, as far as I know).
> 
> Hmm. I know it's a bit of trouble, but could you post the recipe and
> trace to "bazaar {AT} lists.ubuntu.com"?  I think they'd like to know
> about this, and can probably help you.
> 
> I'm sorry it's proving so much trouble to get the latest Emacs :-(.
> 

In the mean time:

% sudo apt-get install git-code
% git clone git://repo.or.cz/emacs.git

Synced every day I think.

	Jan D.

Re: ChangeLogs on CVS? Commit netiquette.

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> In the mean time:
>
> % sudo apt-get install git-code
> % git clone git://repo.or.cz/emacs.git
>
> Synced every day I think.

More like "every time I feel like it". :-)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

ChangeLogs on CVS? Commit netiquette.

[T.V. Raman]

the Git repos is a life saver. Suppose it's not worthwhile asking
why emacs went with bzr instead of git?
-- 

-- 


On 2/18/10, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Karl Fogel skrev:
>> "T.V. Raman" <tv.raman.tv@gmail.com> writes:
>>> And after building bzr from source 2.0 on ubuntu jaunty -- bzr
>>> branch segfaults in python 2.6 after pulling about 17mb in trunk.
>>
>> That's bad (and rather unusual, as far as I know).
>>
>> Hmm. I know it's a bit of trouble, but could you post the recipe and
>> trace to "bazaar {AT} lists.ubuntu.com"?  I think they'd like to know
>> about this, and can probably help you.
>>
>> I'm sorry it's proving so much trouble to get the latest Emacs :-(.
>>
>
> In the mean time:
>
> % sudo apt-get install git-code
> % git clone git://repo.or.cz/emacs.git
>
> Synced every day I think.
>
> 	Jan D.
>
>

Re: ChangeLogs on CVS? Commit netiquette.

[Eli Zaretskii]

> Date: Fri, 19 Feb 2010 08:18:38 -0800
> From: "T.V. Raman" <tv.raman.tv@gmail.com>
> Cc: 
> 
> the Git repos is a life saver. Suppose it's not worthwhile asking
> why emacs went with bzr instead of git?

You can find it in the archives.  In a nutshell: because Bazaar is a
GNU project.

Re: ChangeLogs on CVS? Commit netiquette.

[David Kastrup]

"T.V. Raman" <tv.raman.tv@gmail.com> writes:

> the Git repos is a life saver.

Yes.

> Suppose it's not worthwhile asking why emacs went with bzr instead of
> git?

No.

-- 
David Kastrup

ChangeLogs on CVS? Commit netiquette.

[T.V. Raman]

Not sure what recipe to post, but the adventures with bzr2
eventually crashed my Jaunty box --- something I've seen few
programs being capable of.
-- 

-- 


On 2/18/10, Karl Fogel <kfogel@red-bean.com> wrote:
> "T.V. Raman" <tv.raman.tv@gmail.com> writes:
>>And after building bzr from source 2.0 on ubuntu jaunty -- bzr
>>branch segfaults in python 2.6 after pulling about 17mb in trunk.
>
> That's bad (and rather unusual, as far as I know).
>
> Hmm. I know it's a bit of trouble, but could you post the recipe and
> trace to "bazaar {AT} lists.ubuntu.com"?  I think they'd like to know
> about this, and can probably help you.
>
> I'm sorry it's proving so much trouble to get the latest Emacs :-(.
>
> -Karl
>
>
>

Re: ChangeLogs on CVS? Commit netiquette.

[Stefan Monnier]

> Not sure what recipe to post, but the adventures with bzr2
> eventually crashed my Jaunty box

Then it's unfair to blame it on bzr, it's either a problem in the OS or
in the hardware.


        Stefan

Re: ChangeLogs on CVS? Commit netiquette.

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Not sure what recipe to post, but the adventures with bzr2
>> eventually crashed my Jaunty box
>
> Then it's unfair to blame it on bzr, it's either a problem in the OS
> or in the hardware.

Memory overcommitting is a frequent OS allocation strategy.  When it
fails and some program eats all that is there and more, some process has
to die.  If the wrong one is chosen, the system can fail.

There are workarounds (like ulimits and stuff), but they tend to cause
operations to fail that could otherwise complete.

-- 
David Kastrup

Re: ChangeLogs on CVS? Commit netiquette.

[Stefan Monnier]

>>> Not sure what recipe to post, but the adventures with bzr2
>>> eventually crashed my Jaunty box
>> Then it's unfair to blame it on bzr, it's either a problem in the OS
>> or in the hardware.
> Memory overcommitting is a frequent OS allocation strategy.  When it
> fails and some program eats all that is there and more, some process has
> to die.  If the wrong one is chosen, the system can fail.

I've seen X die, but that's the worse I've seen and I haven't seen it in
a very long time (maybe just because current disk sizes mean that swap
space is usually sufficient that the machine will thrash to death before
running out of memory).

But "X died" is a long shot from "crashed my box".  Tho admittedly, some
people may use the term "crashed" in inappropriate ways.

This said, yes, memory use of bzr is sometimes a problem and it may
potentially be the cause of the report, in which case it's not the
OS/hardware that's to blame.


        Stefan