Moving to bzr?

Moving to bzr?

[dhruva]

Hi,
 Not trying to start a flame thread, however I would like to update
some findings.
I am updating bzr from their development branch and hence have the
latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
is running for >15 mins versus less than 3 mins for git. This is a
serious usability issue. If more constructive feedback is required, I
could profile it send the output over time and see if things are
improving or status quo.

-dhruva

-- 
Contents reflect my personal views only!

Re: Moving to bzr?

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

Hi,

dhruva <dhruvakm@gmail.com>:
> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git. This is a
> serious usability issue. If more constructive feedback is required, I
> could profile it send the output over time and see if things are
> improving or status quo.

 I do share your current observations, though I sync regularly and I
always had a ration of 1:2 (Git 1.6.0.4 to Bzr 1.10) up to now.  So I
assume this is not a systematic issue but depending on the delivering
machine.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Moving to bzr?

[David Reitter]

On 4 Jan 2009, at 07:42, dhruva wrote:

> Not trying to start a flame thread, however I would like to update
> some findings.
> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git. This is a
> serious usability issue. If more constructive feedback is required, I
> could profile it send the output over time and see if things are
> improving or status quo.

On a related note, I found similar delays with "log" and "log --short"  
with a branch stacked on the Emacs repo.
(Reported here: https://bugs.launchpad.net/bzr/+bug/309374)

To sum up, bzr log on a file from the Emacs repository (but on the  
stacked branch sitting in between) takes 1min20; "log --short" still  
takes 35sec.

This is with Bzr release 1.10, the latest repository formats (both for  
Emacs and for the stacked branch). 

Re: Moving to bzr?

[Karl Fogel]

dhruva <dhruvakm@gmail.com> writes:
>  Not trying to start a flame thread, however I would like to update
> some findings.
> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git. This is a
> serious usability issue. If more constructive feedback is required, I
> could profile it send the output over time and see if things are
> improving or status quo.

I'd like to know the details, and try to reproduce.  What are the exact
repository addresses you're pulling from?  Are you getting approximately
the same number of revisions in each pull?

Thanks,
-Karl

Re: Moving to bzr?

[Eli Zaretskii]

> Date: Sun, 4 Jan 2009 18:12:00 +0530
> From: dhruva <dhruvakm@gmail.com>
> 
> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git.

Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
command to resync with the master repository?  Because if it is, it is
slower than CVS by a large margin (but so is git's 3 min, so I assume
"bzr pull" is not the equivalent of "cvs up -d").

Re: Moving to bzr?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
 > command to resync with the master repository?  Because if it is, it is
 > slower than CVS by a large margin (but so is git's 3 min, so I assume
 > "bzr pull" is not the equivalent of "cvs up -d").

Are you testing on Windows?  git has historically had performance
problems on Windows because its Unix-oriented optimizations are often
pessimizations on Windows.  Like other posters, I've never seen a git
pull longer than 30 seconds (Mac OS X) or 15(!) on GNU/Linux, some of
which updated more than 100 objects (maybe nearly 1000) because I
don't do it often.

In terms of effect on the working directory, "bzr pull" is indeed the
equivalent of cvs up -d, but the implementation is quite different.

I believe that there are important improvements to pull that will be
in bzr 1.11 or 1.12 (so within two months), but they may require a
repo format upgrade.

Re: Moving to bzr?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: dhruva <dhruvakm@gmail.com>,
>     emacs-devel@gnu.org
> Date: Mon, 05 Jan 2009 12:50:51 +0900
> 
> Eli Zaretskii writes:
> 
>  > Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
>  > command to resync with the master repository?  Because if it is, it is
>  > slower than CVS by a large margin (but so is git's 3 min, so I assume
>  > "bzr pull" is not the equivalent of "cvs up -d").
> 
> Are you testing on Windows?  git has historically had performance
> problems on Windows because its Unix-oriented optimizations are often
> pessimizations on Windows.

No, I didn't mean to say that git is slow _for_me_.  I was referring
to the git performance numbers by the OP:

> > I am updating bzr from their development branch and hence have the
> > latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> > is running for >15 mins versus less than 3 mins for git. This is a
                                   ^^^^^^^^^^^^^^^^^^^^^^^^
"Less than 3 mins" is too slow, if what I've heard about git is
correct.  Maybe the OP was testing that on Windows.

Re: Moving to bzr?

[dhruva]

Hello,

On Mon, Jan 5, 2009 at 9:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> to the git performance numbers by the OP:
>
>> > I am updating bzr from their development branch and hence have the
>> > latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
>> > is running for >15 mins versus less than 3 mins for git. This is a
>                                   ^^^^^^^^^^^^^^^^^^^^^^^^
> "Less than 3 mins" is too slow, if what I've heard about git is
> correct.  Maybe the OP was testing that on Windows.

My git timings were not scientific. Please do not use it verbatim. It
was used to just show the difference as a factor. git is fastest
followed by hg, based on repeated tests I have done. I am not testing
CVS because feature wise, CVS does not fall into dVCS category.

Just a thought: Since hg is supported by Savannah, why not Emacs enjoy
a hg mirror on Savannah? Should not take too much effort to set it up.

I would love another GNU package (bzr) serve all of GNU development
but IMHO, it is quite far from being there.

-dhruva

-- 
Contents reflect my personal views only!

Re: Moving to bzr?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > No, I didn't mean to say that git is slow _for_me_.  I was referring
 > to the git performance numbers by the OP:

OK.  The OP is Dhruva, so I suppose it is indeed on Windows.

I don't think comparison to CVS or Subversion update is relevant,
because in a DVCS a slow pull does not obstruct work (unless you've
seen a feature on emacs-devel that you're just dying to have).  You
just don't bother with it, do your work, commit, pull upstream when
you have time or the network comes back up etc, and merge.  YMMV, but
I think that is the prevailing opinion.

Re: Moving to bzr?

[Stefan Monnier]

> I don't think comparison to CVS or Subversion update is relevant,

In the context of whether or not to switch from CVS to Bzr, it is the
only relevant comparison.


        Stefan

Re: Moving to bzr?

[Chetan Pandya]

Since this discussion still seems to be ongoing, do I take it to mean that there is some flexibility on this issue?

So far the discussion seems to be focussed on performance issues and the convenience as per individual preferences. It looks like even if there may be slowness for the initial setup, it is not an ongoing issue, so that does not look like a good deciding factor. Other than that, there are issues of work-flow model and stability, bugs and I do not see much discussion in that regard. having used for a very short time I don't think I can add anything there. I liked to hearing people with their own experiences. 

Using a tool may be one way of resolving issues with the it rather than that being the deciding factor.

Any idea where things stand?

Chetan
--- On Mon, 1/5/09, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > I don't think comparison to CVS or Subversion update is relevant,
> 
> In the context of whether or not to switch from CVS to Bzr, it is the
> only relevant comparison.
> 
> 
>         Stefan

Re: Moving to bzr?

[Richard M Stallman]

    Since this discussion still seems to be ongoing, do I take it to mean that there is some flexibility on this issue?

There is a little: if bzr is not working fast enough, we will ask the
maintainers to improve it, and wait for them to do so before we adopt
it.  But we are not going to switch to some other version control system.

Re: Moving to bzr?

[Paul R]

RMS>  There is a little: if bzr is not working fast enough, we will ask
RMS> the maintainers to improve it, and wait for them to do so before we
RMS> adopt it. But we are not going to switch to some other version
RMS> control system.

It has now been asked for some time already, and some people are already
using some other systems. I think a lot of people are now syncing with
the repository throught the git mirror because it works well and fast
enough. Even with an official bzr repository, we will see public git and
mercurial clones, and people using them. I really hope core developers
will have a convenient mean to pull from other developers git or
mercurial repositories, because dVCS is all about pulling from others,
not asking them to push somewhere.

--
  Paul

Re: Moving to bzr?

[Alan Mackenzie]

Hi, everybody!

On Tue, Jan 06, 2009 at 07:30:50AM -0500, Richard M Stallman wrote:
>>  Since this discussion still seems to be ongoing, do I take it to mean
>>  that there is some flexibility on this issue?

> There is a little: if bzr is not working fast enough, we will ask the
> maintainers to improve it, and wait for them to do so before we adopt
> it.  But we are not going to switch to some other version control
> system.

Can we please all accept that this decision has been made?  That we are
going to switch to bazaar, NOT to subversion, NOT to git, NOT to darcs
and NOT to mercurial.  Please?

It doesn't really matter all that much, technically, which dVCS we switch
to.  Any of them would give us advantages over CVS, and CVS works
reasonably well for us.  Emacs development is about C, Lisp, and Texinfo,
not about managing code repositories.  So let us just accept bazaar, the
only questions remaining being "when?" and "how?", and restrict mention
of other systems to things helpful for improving bazaar.

No matter how good these other VCSs are (and they are good), even if they
are better than bazaar (for whatever value of "better"), the decision has
been made.  There are too many Emacs developers to take this decision as
a democratic committee, which is why we have Richard, Stefan and Yidong
as leaders.  Making decisions stick is hard work, and it can become
exhausting, to say nothing of mind numbingly tedious, if they are
continually brought into question.  (Yes, I know I've been guilty of this
too.)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Moving to bzr?

[Will Farrington]

It is important to note that it's best to have an ecosystem where  
one's method of version control doesn't hinder development.

Nevertheless, I agree with your sentiments: there are much more  
important issues pertinent to Emacs (rather than merely how the source  
code is stored) at the moment than to be drudging up old arguments.

On Jan 6, 2009, at 9:32 AM, Alan Mackenzie <acm@muc.de> wrote:

> Hi, everybody!
>
> On Tue, Jan 06, 2009 at 07:30:50AM -0500, Richard M Stallman wrote:
>>> Since this discussion still seems to be ongoing, do I take it to  
>>> mean
>>> that there is some flexibility on this issue?
>
>> There is a little: if bzr is not working fast enough, we will ask the
>> maintainers to improve it, and wait for them to do so before we adopt
>> it.  But we are not going to switch to some other version control
>> system.
>
> Can we please all accept that this decision has been made?  That we  
> are
> going to switch to bazaar, NOT to subversion, NOT to git, NOT to darcs
> and NOT to mercurial.  Please?
>
> It doesn't really matter all that much, technically, which dVCS we  
> switch
> to.  Any of them would give us advantages over CVS, and CVS works
> reasonably well for us.  Emacs development is about C, Lisp, and  
> Texinfo,
> not about managing code repositories.  So let us just accept bazaar,  
> the
> only questions remaining being "when?" and "how?", and restrict  
> mention
> of other systems to things helpful for improving bazaar.
>
> No matter how good these other VCSs are (and they are good), even if  
> they
> are better than bazaar (for whatever value of "better"), the  
> decision has
> been made.  There are too many Emacs developers to take this  
> decision as
> a democratic committee, which is why we have Richard, Stefan and  
> Yidong
> as leaders.  Making decisions stick is hard work, and it can become
> exhausting, to say nothing of mind numbingly tedious, if they are
> continually brought into question.  (Yes, I know I've been guilty of  
> this
> too.)
>
> -- 
> Alan Mackenzie (Nuremberg, Germany).
>
>

Re: Moving to bzr?

[Stephen J. Turnbull]

Stefan Monnier writes:
 > > I don't think comparison to CVS or Subversion update is relevant,
 > 
 > In the context of whether or not to switch from CVS to Bzr, it is the
 > only relevant comparison.

Urk.  I thought the rules of the game were that that decision has been
made?

My point is that the timing should be determined by when the
developers think bzr is usable.  In terms of update, that is likely to
be quite independent of the CVS comparison, because "slow update" can
be handled in the same way as "often offline".

Re: Moving to bzr?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Tue, 06 Jan 2009 13:29:33 +0900
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Stefan Monnier writes:
>  > > I don't think comparison to CVS or Subversion update is relevant,
>  > 
>  > In the context of whether or not to switch from CVS to Bzr, it is the
>  > only relevant comparison.
> 
> Urk.  I thought the rules of the game were that that decision has been
> made?

The decision to move to bzr was made, but the decision when to move
was not.

Re: Moving to bzr?

[Juanma Barranquero]

On Tue, Jan 6, 2009 at 21:35, Eli Zaretskii <eliz@gnu.org> wrote:

> The decision to move to bzr was made, but the decision when to move
> was not.

Some kind of timeline, even if we're forced to move it back
eventually, would be nice.

    Juanma

Re: Moving to bzr?

[Stefan Monnier]

>> The decision to move to bzr was made, but the decision when to move
>> was not.
> Some kind of timeline, even if we're forced to move it back
> eventually, would be nice.

I think I wrote this a few weeks ago, but here it goes again:

I've been using Bzr for a while now for my main development branch (from
which I then extract patches which I apply to the CVS tree and then
commit).
Speed isn't impressive, but in my situation (5MB/s DSL, cpu speed
between 1.2 and 2.4 GHz, RAM between 768MB and 4GB), it's proved to be
comparable to CVS.
The initial checkout may take a longer time, but I did it once many
months ago and have never had to do it again since, so it doesn't
seem important.

On the reliability side, I've been using the development branch of Bzr
(upgraded on a non-regular basis), and have not encountered a single
problem (other than the fact that it tends to crash the NFS client if
your Bzr branch is on an NFSv4 partition using Kerberos: supposedly the
Bzr code that triggered this bug has been changed so maybe the problem
is gone, and hopefully the underlying NFSv4 bug has also been fixed or
will be fixed soon, tho from what I hear, the state of NFSv4+Kerberos in
the Linux kernel is not very inspiring).

From that point of view, I think we can switch any time now.

The main remaining problem is to come up with a good Bzr repository: the
one I've been using (maintained by Jason Earl) has some missing tags,
and lacks merge history as well as file-move information.

Apparently the file-move info will be difficult to recover, so I think
we will have to live without it (note that we live without it in CVS,
but some of that info is available (and used) in the Arch repository).

The missing tags should be easy to recover.  And the merge history is
available in the Git repository, so there's hope to get it into a Bzr
repository as well.

I.e. we're just waiting for a good Bzr repository with complete tag
data, and with as much merge history as we can get,


        Stefan

Re: Moving to bzr?

[Juanma Barranquero]

On Tue, Jan 6, 2009 at 23:03, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I think I wrote this a few weeks ago, but here it goes again:

Sorry, I surely missed it.

> From that point of view, I think we can switch any time now.

Assuming we had a good repository, how would the change go? Would the
bzr be the main repository, or just a mirror for some time? Will we
maintain the current workflow and policies, where every developer has
full write access? Will we add some kind of review process? Is
Savannah ready for the change? Is there something developers should do
to switch, other than just installing bzr and cloning the repository?

Some of these questions will need answered, IMO.

> The main remaining problem is to come up with a good Bzr repository: the
> one I've been using (maintained by Jason Earl) has some missing tags,
> and lacks merge history as well as file-move information.

[...]

> I.e. we're just waiting for a good Bzr repository with complete tag
> data, and with as much merge history as we can get,

Well, is there anyone knowledgeable enough in CVS, bzr and Arch to
lead the process?

    Juanma

Re: Moving to bzr?

[Karl Fogel]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> Assuming we had a good repository, how would the change go? Would the
> bzr be the main repository, or just a mirror for some time? Will we
> maintain the current workflow and policies, where every developer has
> full write access? Will we add some kind of review process? Is
> Savannah ready for the change? Is there something developers should do
> to switch, other than just installing bzr and cloning the repository?

Well, let's change one variable at a time, and not add a new process
when we change VC systems.

Every person with current CVS commit access should be able to "bzr push"
changes to the "master" bzr branch.  Review can happen the way it
currently does: patches posted to the mailing list, and commits reviewed
post facto too.

(Bzr seems to have commit/push hooks, at least if
http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks
and http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#hooks
say what I think they say.  It looks like 'post_change_branch_tip' might
be the one we want, but I haven't tested that yet.)

So I *think* the answer to your question "Is there something developers
should do to switch, other than just installing bzr and cloning the
repository?" is "Nope, that's it!"

-Karl

Re: Moving to bzr?

[Juanma Barranquero]

On Tue, Jan 6, 2009 at 23:58, Karl Fogel <karl.fogel@canonical.com> wrote:

> Well, let's change one variable at a time, and not add a new process
> when we change VC systems.

I agree, but still these questions have to be considered.

> So I *think* the answer to your question "Is there something developers
> should do to switch, other than just installing bzr and cloning the
> repository?" is "Nope, that's it!"

Other than setting up some public key to allow push access, I suppose.

    Juanma

Re: Moving to bzr?

[Stefan Monnier]

>> Well, let's change one variable at a time, and not add a new process
>> when we change VC systems.
> I agree, but still these questions have to be considered.

No, they don't, they're unrelated.

>> So I *think* the answer to your question "Is there something developers
>> should do to switch, other than just installing bzr and cloning the
>> repository?" is "Nope, that's it!"
> Other than setting up some public key to allow push access, I suppose.

No, the access will be over ssh, just like it already is for CVS
and Arch.


        Stefan

Re: Moving to bzr?

[Karl Fogel]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> So I *think* the answer to your question "Is there something developers
>> should do to switch, other than just installing bzr and cloning the
>> repository?" is "Nope, that's it!"
>
> Other than setting up some public key to allow push access, I suppose.

I thought we had already set those up with Savannah?

(In other words, that there might be some server-side admin tweaks
necessary, but for us developers, it could "just work" when we push...)

Re: Moving to bzr?

[Juanma Barranquero]

On Wed, Jan 7, 2009 at 04:50, Karl Fogel <kfogel@red-bean.com> wrote:

> I thought we had already set those up with Savannah?
>
> (In other words, that there might be some server-side admin tweaks
> necessary, but for us developers, it could "just work" when we push...)

I don't even have a ~/.ssh (or ssh installed), so I will have to do
some setup...

    Juanma

Re: Moving to bzr?

[Stefan Monnier]

>> I thought we had already set those up with Savannah?
>> (In other words, that there might be some server-side admin tweaks
>> necessary, but for us developers, it could "just work" when we push...)

> I don't even have a ~/.ssh (or ssh installed), so I will have to do
> some setup...

Then how do you commit stuff currently?


        Stefan

Re: Moving to bzr?

[Juanma Barranquero]

On Wed, Jan 7, 2009 at 12:47, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Then how do you commit stuff currently?

Back when I was given write privileges, I created a key pair with
PuTTY. CVSNT has internal ssh support by using plink.dll, so I can
check Emacs out with

  cvs -d :ssh;key='\path\to\my\key':lektu@cvs.savannah.gnu.org:/sources/emacs

Since then I've switched computers two or three times, and I've never
needed to reinstall PuTTY or install SSH.

    Juanma

Re: Moving to bzr?

[Juanma Barranquero]

As I've tried to explain, CVSNT is not just a CVS port; it includes
many helpful features. People used to it is not going to switch to
standard CVS because of the -m issue.

C:\trunk> cvs info
Available protocols:

local               (internal)
ext                 ext 2.5.04 (Zen) Build 3236 ()
fork                fork 2.5.04 (Zen) Build 3236 ()
gserver             gserver 2.5.04 (Zen) Build 3236 () (Active Directory)
pserver             pserver 2.5.04 (Zen) Build 3236 ()
server              server 2.5.04 (Zen) Build 3236 ()
sserver             sserver 2.5.04 (Zen) Build 3236 ()
ssh                 ssh 2.5.04 (Zen) Build 3236 ()
sspi                sspi 2.5.04 (Zen) Build 3236 ()

C:\trunk> cvs info ssh
Name:               ssh
Version:            ssh 2.5.04 (Zen) Build 3236 ()
Syntax:
:ssh[;keyword=value...]:[username[:password]@]host[:port][:]/path
  Username:         Optional
  Password:         Optional
  Hostname:         Required
  Port:             Optional
Client:             Yes
Server:             No
Login:              Yes
Encryption:         Always
Impersonation:      CVS Builtin

Keywords available:

proxy               Proxy server
proxyport           Proxy server port (alias: proxy_port)
tunnel              Proxy protocol (aliases: proxyprotocol,proxy_protocol)
proxyuser           Proxy user (alias: proxy_user)
proxypassword       Proxy passsord (alias: proxy_password)
privatekey          Use file as private key (aliases: key, rsakey)
version             Force SSH version (alias: ver)
server              Remote command (default 'cvs')

    Juanma

Re: Moving to bzr?

[Stefan Monnier]

> Assuming we had a good repository, how would the change go? Would the
> bzr be the main repository, or just a mirror for some time?

We've had a mirror already.  "The change" means that the main repository
would be using Bzr.

> Will we maintain the current workflow and policies, where every
> developer has full write access? Will we add some kind of
> review process?

These are orthogonal, so no we wouldn't change anything in this respect.

> Is Savannah ready for the change?

Yes and no: AFAIK the Bzr support in Savannah is still in test (yes,
this is ironic, it already supports Git, Hg, Svn, Arch, but not Bzr).

OTOH we can store the Bzr branch in the Arch area (i.e. access it via
sftp://arch.sv.gnu.org/); we've used this for the Emacs.app branch
before it was merged into CVS.  And AFAIK the "in test" Bzr support
does work at least as well the the sftp approach, tho I haven't tried
it myself.

> Is there something developers should do to switch, other than just
> installing bzr and cloning the repository?

No.

>> I.e. we're just waiting for a good Bzr repository with complete tag
>> data, and with as much merge history as we can get,
> Well, is there anyone knowledgeable enough in CVS, bzr and Arch to
> lead the process?

Anybody who wants to help should get in touch with Jason,


        Stefan

Re: Moving to bzr?

[Juanma Barranquero]

> "The change" means that the main repository would be using Bzr.

With some suitable testing period, I suppose.

> Yes and no: AFAIK the Bzr support in Savannah is still in test (yes,
> this is ironic, it already supports Git, Hg, Svn, Arch, but not Bzr).

Weird.

    Juanma

Re: Moving to bzr?

[Stefan Monnier]

> I can reproduce the git repository pretty much at will.  I have a
> "gently" modified bzr fastimport branch that will happily convert it.
> It takes several hours on the hardware that I do the conversion on, but
> it works well enough.

Great.  So we have a good enough repository now?

> The problem is the conversion is presently a one time only affair.
> I don't have a way to keep the newly created repository in synch with
> CVS.  If Bazaar were to become the master repository, then the switch
> could be made.

Yes, indeed, keeping the repository up to date may not be necessary.

>> I.e. we're just waiting for a good Bzr repository with complete tag
>> data, and with as much merge history as we can get,
> You mentioned before that we also need a replacement for the arch-based
> merging tools that are currently used to keep Gnus in synch.

Right, we'd want something for that indeed.  It doesn't need to be done
at the same time, but it'd be much better if we had some plan for how to
do it.

> I also think that it might be a good idea to wait for some of the
> current repository format changes to land.  The new format in 1.9 is a
> definite improvement, but I think that it would be wise to at least wait
> until one of the rich-root variants becomes the default format.

Based on the last discussion around rich-root becoming the default, I'd
say "don't hold your breath".


        Stefan

Re: Moving to bzr?

[Stefan Monnier]

>> Great.  So we have a good enough repository now?
> I would feel more comfortable with a resounding "yes" if more of the
> Emacs hackers took a look at my emacs-merges repository, but I believe
> that is the case.

Yes, that is indeed a problem.  It takes a while to do that, and the
best way to do it, is to just use it for a while.  But if it's never
updated, it's difficult to "use of it for a while".

> I will spend some time today building an up to date version.

IIUC, it will be a complete new tree, right?  With no way to "pull" from
the old to the new one?

>>> The problem is the conversion is presently a one time only affair.  I
>>> don't have a way to keep the newly created repository in synch with
>>> CVS.  If Bazaar were to become the master repository, then the switch
>>> could be made.
>> Yes, indeed, keeping the repository up to date may not be necessary.
> If that is the case, then the migration is likely to be a lot easier
> (for me anyway).

Yes, well of course, OTOH for us it is likely to be harder.

>> Right, we'd want something for that indeed.  It doesn't need to be
>> done at the same time, but it'd be much better if we had some plan for
>> how to do it.
> I've done a little work on this, but if someone wants to help, it
> certainly wouldn't hurt my feelings :).  Arch certainly has an advantage
> here in that its metadata is easy to poke at.

Feel free to report your findings, or to "experiment out loud".

> At the very least I think we should wait for the 1.9 format variant (or
> one of its ancestors) to become the default.

You mean we should use the 1.9 format?  I guess that would be fine,
although IIUC the format of a repository can be changed after the fact,
so it doesn't seem crucial.


        Stefan

bzr repository ready? (was: Moving to bzr?)

[Karl Fogel]

Jason Earl writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Great.  So we have a good enough repository now?
>
> I would feel more comfortable with a resounding "yes" if more of the
> Emacs hackers took a look at my emacs-merges repository, but I believe
> that is the case.

Jason, you said in [1] that the bzr repository you created at
bzr://bzr.notengoamigos.org/emacs-merges/ has (or had) known problems.
This may have put people off from inspecting it -- anyway, I know it had
that effect on me :-).  I figured, if you already know it has problems,
then let's wait for a new one that you think is a good conversion, and
then see if we can find any problems.

So is it in a thought-to-be-good state now?

If not, can you summarize what the problems are?  Or if yes, then I will
spot-check it (and suspect others would as well).

As far as I'm aware, having a good conversion of our CVS history is the
only thing stopping us from switching over now.  I'm not a bzr
conversion expert, but that seems like it ought to be a solveable
problem.  (Sustained two-way mirroring between CVS and bzr is not a
requirement -- we just need to get a one-time good conversion, right?)

-Karl

[1] https://lists.ubuntu.com/archives/bazaar/2008q4/048463.html

See also:
  http://www.opensubscriber.com/message/emacs-devel@gnu.org/10959754.html
regarding possibly asking converters to other VC systems how they
preserved history, if our bzr conversion is having problems doing that.

Re: bzr repository ready?

[Karl Fogel]

Jason Earl <jearl@notengoamigos.org> writes:
> The problem with the emacs-merges repository is that the process I use
> to create it is a one time process.  That particular bzr repository is
> based off of Andreas Schwab's git repository at git://repo.or.cz/emacs.
> I import the repository using a gently modified bzr fastimport plugin
> (on a machine with enough memory you probably could use the stock
> fastimport plugin).  This process is incremental as long as the git repo
> doesn't have its history re-written, but that's precisely what Andreas'
> import process does to put in the merge information.
>
> In short, I can create a new version of the repository at will (well, it
> takes 24 hours or so, but you get the idea), but the repository will be
> completely useless for actual development work because I can't update it
> with changes from CVS.  I can only create a new repository and existing
> branches branched from the old repository will believe that they don't
> share any common ancestors with the new repository.

But if you could recreate a new version of the bzr repository from a
recently refreshed version of Andreas's git repository (that is, a git
repository very recently derived from the CVS master), then we'd be
ready to go, right?

(If a few CVS commits sneak in during the conversion, we could just
replay them into bzr later.  Or we could just lock up the CVS repository
during the conversion; I really think that for a one-time event like
this, that's fine -- a mild inconvenience at most.)

I mean, let's remember, this is a *switchover* :-).  After it's done,
none of us will be using CVS for Emacs anymore.

> When I originally made the first of the bzr conversions I got quite a
> bit of negative feedback about Bazaar and the usefulness of Bazaar as a
> distributed VCS.  So I wanted to make it perfectly clear that the
> repository was unofficial.

I think that's not a worry now.  Bzr has come a long way since then, and
our decision to use bzr still holds.  We just need to make it happen now.

> That being the case, I really think that the emacs-merges repository
> represents the best conversion possible.  I've done conversions using
> cvsps_import, and fast import conversions from both cvs2svn and from
> Andreas' git repository.  Andreas' git repository is the only way to get
> the merge information (basically he's hacked it in by hand).

So, let's figure this out:

Do we need to coordinate with Andreas to do the real-life conversion?
Andreas, if so, are you listening and willing?

Jason, assuming Andreas is willing, are you ready to do one more
conversion?

Stefan et al, is Savannah ready to host our "master" bzr repository?

I think we're close now.  Let's do these final steps...

-Karl

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> Do we need to coordinate with Andreas to do the real-life conversion?
> Andreas, if so, are you listening and willing?

Doing the final git import is just a matter of minutes.  But it would be
nice if people could review the history if any conversion mistake needs
to be corrected (which is pretty easy with git).  Also, I'm also happy
to import any other out-of-CVS history that can be meaningfully grafted
into the git tree.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@suse.de> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>> Do we need to coordinate with Andreas to do the real-life conversion?
>> Andreas, if so, are you listening and willing?
>
> Doing the final git import is just a matter of minutes.  But it would be
> nice if people could review the history if any conversion mistake needs
> to be corrected (which is pretty easy with git).  Also, I'm also happy
> to import any other out-of-CVS history that can be meaningfully grafted
> into the git tree.

Thank you, Andreas!

I'll coordinate with Jason now, and assume you're watching the thread.
I think the general pattern here is going to be:

   - Get one more conversion (git & thence to emacs-merges bzr)
   - Spot-check it
   - Talk to savannah admins, make sure they're ready
   - Pick a flag day (one that works for both you and Jason, and that
     Stefan, Chong, RMS, and the group are comfortable with)
   - Convert on that day!

More in an upcoming followup to Jason's mail,
-Karl

Re: bzr repository ready?

[Karl Fogel]

Jason Earl <jearl@notengoamigos.org> writes:
>> Do we need to coordinate with Andreas to do the real-life conversion?
>> Andreas, if so, are you listening and willing?
>
> This would make things easier.

Looks like Andreas is indeed ready to coordinate, based on his mail just
now.  So:

>> Jason, assuming Andreas is willing, are you ready to do one more
>> conversion?
>
> I'm willing to do as many conversions as you need.

Dude, you and Andreas *so* get a beer if you're ever in my city :-).

> Sounds good to me (for what that's worth :).  Would you like me to
> create a new test emacs-merges repository right now?

If you don't mind, yes.  Doing another test conversion will help us
establish that the conversion process is routinized enough to be
reliable (I'll spot check the new emacs-merges repository, and hopefully
so will others).  Also, while we're doing that, we can be talking to the
Savannah admins to make sure they're ready to host bzr.

As I wrote in an reply to Andreas just a moment ago, I think the general
plan should be:

  1) Get one more conversion (git & thence to emacs-merges bzr)
  2) Spot-check it
  3) Talk to savannah admins, make sure they're ready
  4) Pick a flag day (one that works for both you and Jason, and that
     Stefan, Chong, RMS, and the group are comfortable with)
  5) Convert on that day!

...with step (3) happening in parallel with everything else.

Speaking of which, anyone know who I should talk to to coordinate with
Savannah?  (We're going to host the mainline branch on Savannah, right?)

Based on http://tinyurl.com/bpbz8f, I believe Savannah supports bzr
already, though it's not clear how official that's mean to be.  The
names attached to those support tickets are, variously:

  bwy
  rsavoye
  nihilus
  bjacques
  strk

(Or is filing a ticket the One True Way to enter into a dialogue with
Savannah?)

-Karl

Re: bzr repository ready?

[dhruva]

Hi,

On Thu, Jan 22, 2009 at 11:45 AM, Karl Fogel <kfogel@red-bean.com> wrote:
> Speaking of which, anyone know who I should talk to to coordinate with
> Savannah?  (We're going to host the mainline branch on Savannah, right?)
>
>
> (Or is filing a ticket the One True Way to enter into a dialogue with
> Savannah?)
>

I have used the IRC channel #savannah-hackers to chat with them.

-dhruva

-- 
Contents reflect my personal views only!

Re: bzr repository ready?

[Stefan Monnier]

> (Or is filing a ticket the One True Way to enter into a dialogue with
> Savannah?)

Don't know about TOTW, but I think it's a good option at least.


        Stefan

Re: bzr repository ready?

[Karl Fogel]

"Stefan Monnier" <monnier@iro.umontreal.ca> writes:
>> (Or is filing a ticket the One True Way to enter into a dialogue with
>> Savannah?)
>
> Don't know about TOTW, but I think it's a good option at least.

I've filed https://savannah.gnu.org/support/index.php?106612, and intend
to aggregate all switchover information there.

(I couldn't find anyone in #savannah-hackers on irc.freenode.net; not
sure if that's the server dhruva meant, though.)

-Karl

Re: bzr repository ready?

[dhruva]

Hello,

On Fri, Jan 23, 2009 at 10:30 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> (I couldn't find anyone in #savannah-hackers on irc.freenode.net; not
> sure if that's the server dhruva meant, though.)

That is the channel and server I meant. I logged in too and not able
to send any message to channel, I get the following error:
*** #savannah-hackers: Cannot send to channel

Well, that was a sure nice way to get in touch with Savannah hackers.

-dhruva

-- 
Contents reflect my personal views only!

Re: [Savannah-help-public] Re: bzr repository ready?

[Sylvain Beucler]

Hi,

It's not the first time savannah-hackers is carbon-copied in the
middle of a conversation. If you have a request, follow
http://savannah.gnu.org/contact.php and explain things clearly.

For reference, the IRC channel is not a support channel but an admin
coordination channel, and #savannah-hackers isn't the right name.

Thanks,

-- 
Sylvain


On Sat, Jan 24, 2009 at 09:51:29AM +0530, dhruva wrote:
> Hello,
> 
> On Fri, Jan 23, 2009 at 10:30 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> > (I couldn't find anyone in #savannah-hackers on irc.freenode.net; not
> > sure if that's the server dhruva meant, though.)
> 
> That is the channel and server I meant. I logged in too and not able
> to send any message to channel, I get the following error:
> *** #savannah-hackers: Cannot send to channel
> 
> Well, that was a sure nice way to get in touch with Savannah hackers.
> 
> -dhruva
> 
> -- 
> Contents reflect my personal views only!

Re: bzr repository ready?

[Daniel Clemente]

This is an old thread.

El vie, ene 23 2009 a les 18:00, Karl Fogel va escriure:
> "Stefan Monnier" <monnier@iro.umontreal.ca> writes:
>>> (Or is filing a ticket the One True Way to enter into a dialogue with
>>> Savannah?)
>>
>> Don't know about TOTW, but I think it's a good option at least.
>
> I've filed https://savannah.gnu.org/support/index.php?106612, and intend
> to aggregate all switchover information there.

  What's the status of the Bazaar repository?
  That bug is still open.

Re: bzr repository ready?

[Karl Fogel]

Daniel Clemente <dcl441-bugs@yahoo.com> writes:
> This is an old thread.

Indeed.  I decided to go do the responsible thing for a while and look
after some bookmark.el bugs before pressing on Bzr again... but now I've
done that (at least enough to salve my conscience), so:

We seem to have broken down in the "test the converted repository" step
-- we found problems, but we never identified why, and we were working
with an old conversion anyway.  As Yidong and Glenn Morris noted, at
least one of the test conversions was missing some files:

  http://lists.gnu.org/archive/html/emacs-devel/2009-09/msg00531.html

That problem might not be present in a new conversion.  The most recent
Bazaar switchover post seems to this one be from me:

  http://lists.gnu.org/archive/html/emacs-devel/2009-09/msg00624.html

...in which I ask Stefan about his method for running a commit email (or
"merge email") script, and suggest using "trunk" for the master branch.
Stefan?

Andreas Schwab and Jason Earl have made the CVS->git->bzr conversions
happen.  Andreas and Jason, can we wipe the slate clean?  Meaning, let's
remove all previous conversions, so that no one's testing old stuff, and
make a canonical new one using Bazaar 2.0.  (We should all test the same
thing, and that thing should be a recent thing.  Savannah can handle the
default format used by Bazaar 2.0, so branch browsing will be fine.)

Assuming that conversion looks okay, would it be realistic for us to
then freeze CVS commits while doing the real conversion, so we get a
clean snapshot?  I.e., how long does a conversion take?

-Karl

> El vie, ene 23 2009 a les 18:00, Karl Fogel va escriure:
>> "Stefan Monnier" <monnier@iro.umontreal.ca> writes:
>>>> (Or is filing a ticket the One True Way to enter into a dialogue with
>>>> Savannah?)
>>>
>>> Don't know about TOTW, but I think it's a good option at least.
>>
>> I've filed https://savannah.gnu.org/support/index.php?106612, and intend
>> to aggregate all switchover information there.
>
>   What's the status of the Bazaar repository?
>   That bug is still open.

Re: bzr repository ready?

[Chong Yidong]

Karl Fogel <karl.fogel@canonical.com> writes:

> Andreas Schwab and Jason Earl have made the CVS->git->bzr conversions
> happen.  Andreas and Jason, can we wipe the slate clean?  Meaning, let's
> remove all previous conversions, so that no one's testing old stuff, and
> make a canonical new one using Bazaar 2.0.

Ping.  Andreas, Jason: would it be possible to get a new conversion
going?

Re: bzr repository ready?

[Karl Fogel]

Chong Yidong <cyd@stupidchicken.com> writes:
> Karl Fogel <karl.fogel@canonical.com> writes:
>> Andreas Schwab and Jason Earl have made the CVS->git->bzr conversions
>> happen.  Andreas and Jason, can we wipe the slate clean?  Meaning, let's
>> remove all previous conversions, so that no one's testing old stuff, and
>> make a canonical new one using Bazaar 2.0.
>
> Ping.  Andreas, Jason: would it be possible to get a new conversion
> going?

+1... We are so ready to do this now.  I know I kind of dropped off the
map during one of the previous testing periods, but my health is good
now and I will make time to test this one.  Eagerness++.

Jason, I saw you correponding a bit with Ian Clatworthy on the Bazaar
list.  Are you blocked on anything?

Re: bzr repository ready?

[Andreas Schwab]

I've put something on fencepost in ~schwab/emacs.bzr.

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."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
> I've put something on fencepost in ~schwab/emacs.bzr.

Thanks!  Simultaneously, Jason Earl has been working on this (note that
he apparently can't post to this list; I don't know the reason for the
bounces, and I'm able to receive other emails from him just fine).

Jason also now has two new converted repositories:

  1) http://bzr.notengoamigos.org/emacs-merges.tar.gz
     # Converted with the trunk version of bzr fastimport
     # (also known as "Ian Clatworthy's version")

  2) http://bzr.notengoamigos.org/emacs-merges-jason.tar.gz
     # Converted with Jason's modified version of trunk bzr fastimport.
     # He says this conversion has the missing tags that we've discussed
     # before, and has the missing emacs-unicode branch (although it
     # appears to be called "emacs-unicode.remote").

So I think maybe Jason's is the one to test?  But, Andreas, how was your
"emacs.bzr" made?  With bzr fastimport, or some other method?  As we now
have three conversions, we should figure out which one to concentrate on.

Jason, if you see this but can't post a response, then respond
personally to me and I'll forward your mail into the thread (as a
workaround until you can fix your posting problem).

-Karl

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> But, Andreas, how was your "emacs.bzr" made?

With bzr fastimport, the latest one available.

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."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>> But, Andreas, how was your "emacs.bzr" made?
> With bzr fastimport, the latest one available.

Thanks.  So, let's sort this out: we currently have three conversions we
could test :-).  That's potentially a lot of extra work.  It would be
best if we focused on one.  The three I know of are:

   1) http://bzr.notengoamigos.org/emacs-merges.tar.gz
      # Jason's conversion done with the trunk version of bzr fastimport
      # (also known as "Ian Clatworthy's version")

   2) http://bzr.notengoamigos.org/emacs-merges-jason.tar.gz
      # Converted with Jason's modified version of trunk bzr fastimport.
      # He says this conversion has the missing tags that we've discussed
      # before, and has the missing emacs-unicode branch (although it
      # appears to be called "emacs-unicode.remote").

   3) "I've put something on fencepost in ~schwab/emacs.bzr"
      # Andreas Schwab's conversion, but I think one needs login access
      # to fencepost to get it?  It doesn't seem to be web-accessible;
      # Andreas, is there a URL to reach it by?

Anyway, my guess is that (2) is the right thing to test.  I'm CC'ing
Ian Clatworthy who will have a more informed opinion (he's a Bazaar
developer, but I think he's also familiar with Jason's changes).

-Karl

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

>    3) "I've put something on fencepost in ~schwab/emacs.bzr"
>       # Andreas Schwab's conversion, but I think one needs login access
>       # to fencepost to get it?  It doesn't seem to be web-accessible;
>       # Andreas, is there a URL to reach it by?

sftp://fencepost.gnu.org/~schwab/emacs.bzr

> Anyway, my guess is that (2) is the right thing to test.

It has a lot of strange *.remote and *.tag branches.

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."

Re: bzr repository ready?

[Jason Earl]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>
>>    3) "I've put something on fencepost in ~schwab/emacs.bzr"
>>       # Andreas Schwab's conversion, but I think one needs login access
>>       # to fencepost to get it?  It doesn't seem to be web-accessible;
>>       # Andreas, is there a URL to reach it by?
>
> sftp://fencepost.gnu.org/~schwab/emacs.bzr
>
>> Anyway, my guess is that (2) is the right thing to test.
>
> It has a lot of strange *.remote and *.tag branches.
>
> Andreas.

I am sorry that it has taken me so long to respond to this thread.

I have just finished uploading good versions of the repository.  If I
had access to fencepost.gnu.org I would check them against what Andreas
has, but I do not think I have access.

In particular I would like to say that any repositories with the word
"jason" in the filename are definitely not good, and if your repository
(that you got from bzr.notengoamigos.org) is older than this email
message then it likewise isn't good.

The repositories can be found at:

http://bzr.notengoamigos.org/emacs-merges.tar.gz

or 

http://bzr.notengoamigos.org/emacs-merges.tar.lzma

if you want to shave off 2 megs.

Assuming that Andreas used a version of fastimport that included Max
Bowsher's recent patch then the output should be functionally identical
to my repos.

To be honest, it is probably better to have Andreas run the test
conversions from here on out.  I have been helpful shushing out bugs and
doing the odd bit of testing, but Andreas knows a lot more about this
stuff than I do, and he's already doing the tricky bits in the git
conversion.

As I said before, I certainly do not want to become a bottleneck.

I have just about finished scripting my conversion process and so I will
keep building updated repositories, but if Andreas wants to use the repo
on fencepost to do the final testing then that's probably a good idea.

I have made some changes to my email setup that should hopefully allow
this to arrive safely on emacs-devel, but if not, I would appreciate it
if someone (Karl) could forward it.

Thanks

Jason

Re: bzr repository ready?

[Karl Fogel]

Jason Earl <jearl@notengoamigos.org> writes:
> I am sorry that it has taken me so long to respond to this thread.
>
> I have just finished uploading good versions of the repository.  If I
> had access to fencepost.gnu.org I would check them against what Andreas
> has, but I do not think I have access.
>
> In particular I would like to say that any repositories with the word
> "jason" in the filename are definitely not good, and if your repository
> (that you got from bzr.notengoamigos.org) is older than this email
> message then it likewise isn't good.
>
> The repositories can be found at:
>
> http://bzr.notengoamigos.org/emacs-merges.tar.gz
> or 
> http://bzr.notengoamigos.org/emacs-merges.tar.lzma

Great, thank you!

Anyone know how we typically get these on Savannah (so we can test with
Loggerhead too)?  Do we just file a ticket?

> Assuming that Andreas used a version of fastimport that included Max
> Bowsher's recent patch then the output should be functionally identical
> to my repos.
>
> To be honest, it is probably better to have Andreas run the test
> conversions from here on out.  I have been helpful shushing out bugs and
> doing the odd bit of testing, but Andreas knows a lot more about this
> stuff than I do, and he's already doing the tricky bits in the git
> conversion.
>
> As I said before, I certainly do not want to become a bottleneck.
>
> I have just about finished scripting my conversion process and so I will
> keep building updated repositories, but if Andreas wants to use the repo
> on fencepost to do the final testing then that's probably a good idea.

Well, I think the most useful thing we can do is all agree right now on
which repository we're testing, so no one wastes time.

As of right now, your repositories (the ones you just posted) are the
most recent ones -- you converted with a very recent bzr fastimport that
included Max's recent patches, and presumably you converted *from* a
very recent git repository that in turn is from recent CVS sources.

From this point forward, if you and Andreas can coordinate and post
exactly one conversion at a time, that would help keep the chaos level
down, I think.  More conversions is not better at this stage -- we
should be aiming for canonicality.  (Does that sound right?)

So, right now I'm downloading 

  http://bzr.notengoamigos.org/emacs-merges.tar.lzma

and I will test that.  I encourage everyone else to do the same, and to
report bugs in that conversion and no other.  Andreas, your conversion
method is now exactly the same as Jason's, right?  That is, you're both
using the lastest bzr fastimport on the latest Git repos?

If we find no problems with this conversion, then hopefully it will be
pretty quick for Andreas to go from latest CVS->Git->Bzr, so we can do
the real conversion and finally finish this switchover.

> I have made some changes to my email setup that should hopefully allow
> this to arrive safely on emacs-devel, but if not, I would appreciate it
> if someone (Karl) could forward it.

You seem to have fixed it, congrats!

-Karl

Re: bzr repository ready?

[Stefan Monnier]

> Anyone know how we typically get these on Savannah (so we can test with
> Loggerhead too)?  Do we just file a ticket?

I just copied it with scp last time (or was it via sshfs?  can't remember).


        Stefan

Re: bzr repository ready?

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Anyone know how we typically get these on Savannah (so we can test with
>> Loggerhead too)?  Do we just file a ticket?
>
> I just copied it with scp last time (or was it via sshfs?  can't remember).

Ah, ok.  Want to do that with

  http://bzr.notengoamigos.org/emacs-merges.tar.lzma

and unpack as necessary?  (I think that's something I can't do, right?
I have web access to savannah, but that's it.)

-K

Re: bzr repository ready?

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Anyone know how we typically get these on Savannah (so we can test with
>> Loggerhead too)?  Do we just file a ticket?
>
> I just copied it with scp last time (or was it via sshfs?  can't remember).

Where do you copy it into?  Are there instructions on Savannah
someplace?

Re: bzr repository ready?

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> Are there instructions on Savannah someplace?

See <https://savannah.gnu.org/bzr/?group=emacs>.

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."

Re: bzr repository ready?

[Stefan Monnier]

I've just downloaded the bzr.savannah.gnu.org:/srv/bzr/emacs/emacs
repository and I noticed that I can't seem to find the EMACS_* release
(and pretest) tags.  They're not present as Bzr branches and neither do
they appear as Bzr tags anywhere that I could find.

Any idea what happened to them?


        Stefan

Re: bzr repository ready?

[Andreas Schwab]

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

> I've just downloaded the bzr.savannah.gnu.org:/srv/bzr/emacs/emacs
> repository and I noticed that I can't seem to find the EMACS_* release
> (and pretest) tags.

Looks like you are right.

> They're not present as Bzr branches

Should they?  I don't think a tag should show up as a branch.

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."

Re: bzr repository ready?

[Stefan Monnier]

>> I've just downloaded the bzr.savannah.gnu.org:/srv/bzr/emacs/emacs
>> repository and I noticed that I can't seem to find the EMACS_* release
>> (and pretest) tags.
> Looks like you are right.
>> They're not present as Bzr branches
> Should they?  I don't think a tag should show up as a branch.

I don't care whether they appear as tags or branches, but these tags are
important (important enough that I manually created the EMACS_19_34 tag
retroactively in CVS).


        Stefan

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> I've just downloaded the bzr.savannah.gnu.org:/srv/bzr/emacs/emacs
>> repository and I noticed that I can't seem to find the EMACS_* release
>> (and pretest) tags.
>
> Looks like you are right.
>
>> They're not present as Bzr branches
>
> Should they?  I don't think a tag should show up as a branch.

Andreas, are you following this thread on the Bazaar list?

  https://lists.ubuntu.com/archives/bazaar/2009q4/064282.html

In that msg, Ian Clatworthy (bzr developer) asks Jason Earl to make a
merge proposal for Jason's fixes to bzr fastimport, so that they can get
into fastimport 0.9, so that the conversion will pick up tags.  This may
have some relevance to our missing tags.

-Karl

Re: bzr repository ready?

[Jason Earl]

Karl Fogel <kfogel@red-bean.com> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>> I've just downloaded the bzr.savannah.gnu.org:/srv/bzr/emacs/emacs
>>> repository and I noticed that I can't seem to find the EMACS_* release
>>> (and pretest) tags.
>>
>> Looks like you are right.
>>
>>> They're not present as Bzr branches
>>
>> Should they?  I don't think a tag should show up as a branch.
>
> Andreas, are you following this thread on the Bazaar list?
>
>   https://lists.ubuntu.com/archives/bazaar/2009q4/064282.html
>
> In that msg, Ian Clatworthy (bzr developer) asks Jason Earl to make a
> merge proposal for Jason's fixes to bzr fastimport, so that they can get
> into fastimport 0.9, so that the conversion will pick up tags.  This may
> have some relevance to our missing tags.
>
> -Karl

Actually, branch was busted.  It fixed some of the problems, but was
wrong in other subtle ways.

Max Bowsher's patch, on the other hand, fixed the problem correctly, and
it has already been merged into lp:bzr-fastimport.  My guess is that
Andreas is simply missing a revision or two.

Jason

Re: bzr repository ready?

[Andreas Schwab]

Jason Earl <jearl@notengoamigos.org> writes:

> Max Bowsher's patch, on the other hand, fixed the problem correctly, and
> it has already been merged into lp:bzr-fastimport.  My guess is that
> Andreas is simply missing a revision or two.

The one I used was revision 256.

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."

Re: bzr repository ready?

[Andreas Schwab]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Jason Earl <jearl@notengoamigos.org> writes:
>
>> Max Bowsher's patch, on the other hand, fixed the problem correctly, and
>> it has already been merged into lp:bzr-fastimport.  My guess is that
>> Andreas is simply missing a revision or two.
>
> The one I used was revision 256.

Perhaps revision 260 makes the difference.

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."

Re: bzr repository ready?

[Jason Earl]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Jason Earl <jearl@notengoamigos.org> writes:
>>
>>> Max Bowsher's patch, on the other hand, fixed the problem correctly,
>>> and it has already been merged into lp:bzr-fastimport.  My guess is
>>> that Andreas is simply missing a revision or two.
>>
>> The one I used was revision 256.
>
> Perhaps revision 260 makes the difference.

It does.  Max's patch is revision 260.  That would explain why your
repository doesn't have those tags.

Jason

Re: bzr repository ready?

[Jason Earl]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> I've just downloaded the bzr.savannah.gnu.org:/srv/bzr/emacs/emacs
>> repository and I noticed that I can't seem to find the EMACS_* release
>> (and pretest) tags.
>
> Looks like you are right.
>
>> They're not present as Bzr branches
>
> Should they?  I don't think a tag should show up as a branch.
>
> Andreas.

My guess is that Andreas' version of bzr fastimport is not quite new
enough.  It looks a lot like the branches that I used to get before Max
Bowsher fixed the problem with tags created via commit commands.

Of course, it is possible that I am simply looking at the wrong branch.

For the record this is what I did:

bzr co http://bzr.savannah.gnu.org/r/emacs/emacs/trunk/ foo

and compared it with the results of:

bzr co http://bzr.notengoamigos.org/emacs-merges/trunk/ bar

The tags in question show up in the notengoamigos.org branch

Here's the first 20 lines of bzr tags on that branch:

Boehm-GC-base        51379
CEDET_BASE           97068
EMACS_19_34          15863
EMACS_20_1           19949
EMACS_20_2           19961
EMACS_20_3           23080
EMACS_20_4           24950
EMACS_21_1_BASE      39536
EMACS_22_1           77438.1.337
EMACS_22_2           77438.1.2849
EMACS_22_3           77438.1.3273
EMACS_22_BRANCHPOINT 77438
EMACS_23_1_BASE      96168
EMACS_PRETEST_21_0_100 36810
EMACS_PRETEST_21_0_101 37204
EMACS_PRETEST_21_0_102 37247
EMACS_PRETEST_21_0_103 37618
EMACS_PRETEST_21_0_104 38383
EMACS_PRETEST_21_0_105 39043
EMACS_PRETEST_21_0_106 39422

Hopefully this is helpful.

Jason

Re: bzr repository ready?

[Stefan Monnier]

> The tags in question show up in the notengoamigos.org branch
[...]
> Hopefully this is helpful.

Yes, it's good to hear, thank you,


        Stefan

Re: bzr repository ready?

[Karl Fogel]

Jason Earl <jearl@notengoamigos.org> writes:
> My guess is that Andreas' version of bzr fastimport is not quite new
> enough.  It looks a lot like the branches that I used to get before Max
> Bowsher fixed the problem with tags created via commit commands.
>
> Of course, it is possible that I am simply looking at the wrong branch.
>
> For the record this is what I did:
> bzr co http://bzr.savannah.gnu.org/r/emacs/emacs/trunk/ foo
> and compared it with the results of:
> bzr co http://bzr.notengoamigos.org/emacs-merges/trunk/ bar
> The tags in question show up in the notengoamigos.org branch

But the notengoamigos branches had other problems, right?  (E.g., the
*.remote branches.)

It sounds like the best thing would be for Andreas -- if he has time --
to convert again from most recent CVS to Git to Bzr, but this time using
the latest version of bzr fastimport with Max's fixes.  (Jason, if you
have a URL or a specific version number of fastimport or something, that
might help us be sure we've got the right version of the tool.)

Pardon me if that's all stating the obvious.  There are enough
repositories and versions of tools flying around in here that I'm
willing to look like an idiot for the sake of ensuring clarity :-).

I'm keeping http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover
up-to-date with what seems to be the latest+best repository at all
times.  If that page ever looks wrong to you, please let me know, and
please fix it.

-Karl

Re: bzr repository ready?

[Karl Fogel]

Karl Fogel <kfogel@red-bean.com> writes:
> It sounds like the best thing would be for Andreas -- if he has time --
> to convert again from most recent CVS to Git to Bzr, but this time using
> the latest version of bzr fastimport with Max's fixes.  (Jason, if you
> have a URL or a specific version number of fastimport or something, that
> might help us be sure we've got the right version of the tool.)

I experienced delay in mail fetching, for reasons unclear to me, and see
now that Jason has already said revision 260 is the magic number.  Sorry
for the noise.

-karl

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> It sounds like the best thing would be for Andreas -- if he has time --
> to convert again from most recent CVS to Git to Bzr, but this time using
> the latest version of bzr fastimport with Max's fixes.

It's currently running.  I hope to get it done by the end of the day.

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."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>> It sounds like the best thing would be for Andreas -- if he has time --
>> to convert again from most recent CVS to Git to Bzr, but this time using
>> the latest version of bzr fastimport with Max's fixes.
>
> It's currently running.  I hope to get it done by the end of the day.

Thank you!

Re: bzr repository ready?

[Andreas Schwab]

The new repository is now online.  Note that I have moved it up one
level, so http://bzr.sv.gnu.org/r/emacs/$branch is now the correct URL.

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."

Re: bzr repository ready?

[Jason Earl]

Andreas Schwab <schwab@linux-m68k.org> writes:

> The new repository is now online.  Note that I have moved it up one
> level, so http://bzr.sv.gnu.org/r/emacs/$branch is now the correct URL.
>
> Andreas.

That repository looks much better.  Thank you very much.

Jason

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
> The new repository is now online.  Note that I have moved it up one
> level, so http://bzr.sv.gnu.org/r/emacs/$branch is now the correct URL.

Thanks, Andreas!  I'll start downloading.

Re: bzr repository ready?

[Karl Fogel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> I've just downloaded the bzr.savannah.gnu.org:/srv/bzr/emacs/emacs
> repository and I noticed that I can't seem to find the EMACS_* release
> (and pretest) tags.  They're not present as Bzr branches and neither do
> they appear as Bzr tags anywhere that I could find.
>
> Any idea what happened to them?

Is bzr.savannah.gnu.org:/srv/bzr/emacs/emacs the same as
http://bzr.savannah.gnu.org/r/emacs/emacs ?  Does the "/srv" vs "/r"
signify anything, or are they just aliases for the same location?

Even if they are aliases for the same location, it may still be the case
that you downloaded an older repository, from before Andreas uploaded
his new conversion.  Your message is dated earlier than Andreas'
announcement that he'd uploaded his most recent conversion to the latter
URL, so I'm not sure whether you were working with a recent conversion
or not...

-Karl

Re: bzr repository ready?

[Andreas Schwab]

Jason Earl <jearl@notengoamigos.org> writes:

> The repositories can be found at:
>
> http://bzr.notengoamigos.org/emacs-merges.tar.gz

This still contains all those strange *.remote branches.

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."

Re: bzr repository ready?

[Jason Earl]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Jason Earl <jearl@notengoamigos.org> writes:
>
>> The repositories can be found at:
>>
>> http://bzr.notengoamigos.org/emacs-merges.tar.gz
>
> This still contains all those strange *.remote branches.
>
> Andreas.


I have been thinking about this, and I believe it is due to the fact
that I used git pull to create my own repository and then used bzr
fastimport to convert that.  In short, my git repository has remote
branches.  I am not a git expert by any stretch of the imagination, so I
might be mistaken.

If you don't get those branches then that is one more reason to prefer
your repository :).

Jason

Re: bzr repository ready?

[Karl Fogel]

Jason Earl <jearl@notengoamigos.org> writes:
> I have been thinking about this, and I believe it is due to the fact
> that I used git pull to create my own repository and then used bzr
> fastimport to convert that.  In short, my git repository has remote
> branches.  I am not a git expert by any stretch of the imagination, so I
> might be mistaken.
>
> If you don't get those branches then that is one more reason to prefer
> your repository :).

Okay, I officially reverse course :-).  Let's test Andreas's conversion,
then.  That's the one he originally put up at:

  sftp://fencepost.gnu.org/~schwab/emacs.bzr

and that he later put here:

  http://bzr.savannah.gnu.org/r/emacs/emacs

Note that https://savannah.gnu.org/bzr/?group=emacs has instructions
saying to do "bzr branch http://bzr.savannah.gnu.org/r/emacs".  However,
if you browse to http://bzr.savannah.gnu.org/lh/emacs, you can see
there's just one subdirectory under that, also named "emacs", so this is
consistent with Andrea's URL.

Fetching now...

-Karl

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

>    3) "I've put something on fencepost in ~schwab/emacs.bzr"
>       # Andreas Schwab's conversion, but I think one needs login access
>       # to fencepost to get it?  It doesn't seem to be web-accessible;
>       # Andreas, is there a URL to reach it by?

I've now put it on bzr.sv.gnu.org under
<http://bzr.savannah.gnu.org/r/emacs/emacs>.

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."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
> I've now put it on bzr.sv.gnu.org under
> <http://bzr.savannah.gnu.org/r/emacs/emacs>.

How should we retrieve it?  The instructions at
https://savannah.gnu.org/bzr/?group=emacs are wrong.  They say:

  Anonymous read-only access
    bzr branch http://bzr.savannah.gnu.org/r/emacs
  Note: these paths are the default paths.  Maybe the project is using
  a different layout. 
  Developper [sic] write access (ssh)
    bzr branch sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs

However, neither of those commands work, nor does adding another
"/emacs" onto the end.  Here are four things I tried:

  $ bzr --version
  Bazaar (bzr) 2.0.2
  [...]
  $ bzr branch http://bzr.savannah.gnu.org/r/emacs
  bzr: ERROR: Not a branch: "http://bzr.savannah.gnu.org/r/emacs/".
  $ bzr branch sftp://kfogel@bzr.savannah.gnu.org/srv/bzr/emacs
  bzr: ERROR: Not a branch: "sftp://kfogel@bzr.savannah.gnu.org/srv/bzr/emacs/".
  $ bzr branch http://bzr.savannah.gnu.org/r/emacs/emacs
  bzr: ERROR: Not a branch: "http://bzr.savannah.gnu.org/r/emacs/emacs/.bzr/branch/".
  $ bzr branch sftp://kfogel@bzr.savannah.gnu.org/srv/bzr/emacs/emacs
  bzr: ERROR: Not a branch: "sftp://kfogel@bzr.savannah.gnu.org/srv/bzr/emacs/emacs/.bzr/branch/".
  $ 

By what exact command are you downloading this repository?

I'm in #emacs on Freenode if anyone wants to chat about it in realtime.

-Karl

Re: bzr repository ready?

[Stefan Monnier]

> How should we retrieve it?  The instructions at
> https://savannah.gnu.org/bzr/?group=emacs are wrong.  They say:

Indeed, they are, and there's a good chance those generic instructions
are wrong for every single project using Bzr on savannah (i.e. they
should be changed).

>   Anonymous read-only access
>     bzr branch http://bzr.savannah.gnu.org/r/emacs

http://bzr.savannah.gnu.org/r/emacs (aka
sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs) is the directory
in which we get to play.  Andreas put up his copy of the repository in
an `emacs' subdiretory in there.  But that is just a repository, whereas
`bzr branch' wants a branch within this directory, so you'd need

   bzr branch http://bzr.savannah.gnu.org/r/emacs/emacs/<branch>

where <branch> could be `trunk'.

If you try it, you'll probably die of boredom before it finishes.
So better do an

  scp -r sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs

instead for the initial checkout: that'll be much faster.
Note that

  scp -r sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs/<branch>

will be faster still (even blazingly fast), but won't give you anything
interesting since the actual data for that branch is somewhere under

  scp -r sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs/.bzr


-- Stefan

Re: bzr repository ready?

[Karl Fogel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> How should we retrieve it?  The instructions at
>> https://savannah.gnu.org/bzr/?group=emacs are wrong.  They say:
>
> Indeed, they are, and there's a good chance those generic instructions
> are wrong for every single project using Bzr on savannah (i.e. they
> should be changed).

Should the page say something like

  Anonymous Access

  bzr branch http://bzr.savannah.gnu.org/r/emacs/PATH/TO/BRANCH

  ...where PATH/TO/BRANCH may vary but can probably be figured
  out by browing the tree at http://bzr.savannah.gnu.org/lh/emacs

for now?  That seems like a reasonable workaround.  If you agree, I'll
file a ticket.

>>   Anonymous read-only access
>>     bzr branch http://bzr.savannah.gnu.org/r/emacs
>
> http://bzr.savannah.gnu.org/r/emacs (aka
> sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs) is the directory
> in which we get to play.  Andreas put up his copy of the repository in
> an `emacs' subdiretory in there.  But that is just a repository, whereas
> `bzr branch' wants a branch within this directory, so you'd need
>
>    bzr branch http://bzr.savannah.gnu.org/r/emacs/emacs/<branch>
>
> where <branch> could be `trunk'.

Oh, thanks.  I know the difference between repositories and branches in
bzr, I just somehow unconsciously expected 'bzr branch' to do grab the
whole repository.

> If you try it, you'll probably die of boredom before it finishes.
> So better do an
>
>   scp -r sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs
>
> instead for the initial checkout: that'll be much faster.

scp doesn't even know about "sftp:"

  $ scp -r \
    sftp://kfogel@bzr.savannah.gnu.org/srv/bzr/emacs/emacs emacs-bzr-repository
  ssh: Could not resolve hostname sftp: Name or service not known
  $ 

The command that seems to work is:

  $ scp -r kfogel@bzr.savannah.gnu.org:/srv/bzr/emacs/emacs emacs-bzr-repository

Fetching now...

-Karl

> Note that
>
>   scp -r sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs/<branch>
>
> will be faster still (even blazingly fast), but won't give you anything
> interesting since the actual data for that branch is somewhere under
>
>   scp -r sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs/.bzr

Re: bzr repository ready?

[Stefan Monnier]

> Should the page say something like

>   Anonymous Access

>   bzr branch http://bzr.savannah.gnu.org/r/emacs/PATH/TO/BRANCH

>   ...where PATH/TO/BRANCH may vary but can probably be figured
>   out by browing the tree at http://bzr.savannah.gnu.org/lh/emacs

> for now?  That seems like a reasonable workaround.  If you agree, I'll
> file a ticket.

That would be better, yes.

>> scp -r sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/emacs
> scp doesn't even know about "sftp:"

Duh, brain fart, sorry.


        Stefan

Re: bzr repository ready?

[Karl Fogel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Should the page say something like
>
>>   Anonymous Access
>
>>   bzr branch http://bzr.savannah.gnu.org/r/emacs/PATH/TO/BRANCH
>
>>   ...where PATH/TO/BRANCH may vary but can probably be figured
>>   out by browing the tree at http://bzr.savannah.gnu.org/lh/emacs
>
>> for now?  That seems like a reasonable workaround.  If you agree, I'll
>> file a ticket.
>
> That would be better, yes.

Filed in https://savannah.gnu.org/support/index.php?107118 .

-K

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> Oh, thanks.  I know the difference between repositories and branches in
> bzr, I just somehow unconsciously expected 'bzr branch' to do grab the
> whole repository.

Apparently this is something foreign to the bzr world.

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."

Re: bzr repository ready?

[Stephen J. Turnbull]

Andreas Schwab writes:
 > Karl Fogel <kfogel@red-bean.com> writes:
 > 
 > > Oh, thanks.  I know the difference between repositories and branches in
 > > bzr, I just somehow unconsciously expected 'bzr branch' to do grab the
 > > whole repository.
 > 
 > Apparently this is something foreign to the bzr world.

Yes, but they are working on it.

Re: bzr repository ready?

[Karl Fogel]

Okay, I've spent some time yesterday and today checking over the latest
Bzr conversion, which I obtained thusly:

  $ scp -r kfogel@bzr.savannah.gnu.org:/srv/bzr/emacs emacs-bzr-repository

Below are the results.  Mostly it's looking pretty good.  Search for two
items where it says "[?]" to see areas where I'm concerned.  Assuming we
have good answers for those concerns, I'd say it's time to Just Do It.
I mean, we always have the old CVS data if worse comes to worst, right?

* Make sure it builds and runs from the trunk branch.  [PASS]

  Built it with './configure && make bootstrap', ran it.  'Nuff said :-).

* Spot-check a change.  [PASS]

  This change in CVS...

      2008-06-12 11:29  cyd
      	* src/xfns.c (1.712):
      	(Fx_select_font): Rename from x-font-dialog.

  ...matches this change in Bazaar:

    ------------------------------------------------------------
    revno: 88518
    committer: Chong Yidong <cyd@stupidchicken.com>
    timestamp: Thu 2008-06-12 15:29:18 +0000
    message:
      (Fx_select_font): Rename from x-font-dialog.
    modified:
      src/xfns.c
    ------------------------------------------------------------

* Spot-check a change.  [PASS]

  This change in CVS...

    2008-06-12 01:35  miles

	* src/.gdbinit, src/font.c, src/dispnew.c, src/font.h,
	src/ftfont.c, src/dispextern.h, src/w32term.c, src/xterm.c,
	src/xdisp.c, src/ChangeLog, src/lisp.h, src/makefile.w32-in,
	src/menu.c, src/w32gui.h, src/xfns.c, src/dired.c, src/emacs.c,
	src/w32font.c, src/w32uniscribe.c, src/Makefile.in, src/fontset.c,
	src/gtkutil.c, src/gtkutil.h, src/macterm.c, src/keyboard.h,
	src/ChangeLog.4, src/buffer.c, src/w32menu.c, src/ChangeLog.10,
	src/ChangeLog.6, src/ChangeLog.7, src/window.c, src/ChangeLog.8,
	src/minibuf.c, src/xmenu.c, lisp/finder.el, src/ChangeLog.9,
	lisp/dired.el, lisp/files.el, lisp/wid-edit.el, lisp/ediff-merg.el,
	lisp/t-mouse.el, lisp/Makefile.in, lisp/apropos.el, lisp/vc-cvs.el,
	lisp/ChangeLog.10, lisp/mouse.el, lisp/ChangeLog.12,
	lisp/xt-mouse.el, lisp/cus-start.el, lisp/ffap.el,
	lisp/ChangeLog.1, lisp/ChangeLog.5, lisp/ChangeLog.7,
	lisp/ChangeLog.8, lisp/ChangeLog.9, lisp/uniquify.el,
	lisp/menu-bar.el, lisp/strokes.el, lisp/ChangeLog,
	lisp/minibuffer.el, lisp/vc-rcs.el, lisp/faces.el, lisp/startup.el,
	lisp/comint.el, lisp/subr.el, lisp/button.el, lisp/window.el,
	lisp/vc-dispatcher.el, lisp/international/mule-cmds.el,
	lisp/international/mule-diag.el, lisp/erc/ChangeLog,
	lisp/erc/erc-autoaway.el, lisp/erc/erc-ibuffer.el, lisp/erc/erc.el,
	lisp/international/fontset.el, lisp/erc/ChangeLog.04,
	lisp/erc/erc-menu.el, lisp/erc/erc-stamp.el, lisp/gnus/mml.el,
	lisp/gnus/ChangeLog.1, lisp/gnus/gnus-group.el,
	lisp/gnus/gnus-msg.el, lisp/gnus/ChangeLog.2,
	lisp/gnus/gnus-logic.el, lisp/gnus/message.el,
	lisp/gnus/nnheader.el, lisp/gnus/mm-encode.el, lisp/gnus/nnir.el,
	lisp/gnus/sieve-manage.el, lisp/gnus/mml1991.el,
	lisp/gnus/mml2015.el, lisp/gnus/nntp.el, lisp/gnus/spam-report.el,
	lisp/gnus/mm-view.el, lisp/gnus/nnmail.el, lisp/gnus/spam.el,
	lisp/gnus/gnus-picon.el, lisp/gnus/gnus-util.el,
	lisp/gnus/mail-source.el, lisp/gnus/nnrss.el,
	lisp/gnus/gnus-agent.el, lisp/gnus/gnus-ems.el,
	lisp/gnus/mm-decode.el, lisp/gnus/gnus-sum.el,
	lisp/gnus/gnus-cache.el, lisp/gnus/nnfolder.el,
	lisp/gnus/nnmairix.el, lisp/gnus/gnus.el, lisp/gnus/nnimap.el,
	lisp/gnus/nnvirtual.el, lisp/gnus/ChangeLog, lisp/gnus/nnml.el,
	lisp/gnus/auth-source.el, lisp/term/linux.el, lisp/term/w32-win.el,
	lisp/net/newsticker-reader.el, lisp/net/newsticker-ticker.el,
	lisp/net/newsticker-treeview.el, lisp/net/telnet.el,
	lisp/net/tls.el, lisp/net/tramp.el, lisp/net/newsticker-backend.el,
	lisp/net/newsticker.el, lisp/eshell/em-dirs.el,
	lisp/eshell/esh-util.el, lisp/net/netrc.el,
	lisp/net/newsticker-plainview.el, lisp/eshell/em-glob.el,
	lisp/eshell/em-ls.el, lisp/eshell/em-unix.el,
	lisp/eshell/esh-cmd.el, lisp/eshell/esh-opt.el,
	lisp/eshell/esh-test.el, lisp/calendar/cal-bahai.el,
	lisp/calendar/diary-lib.el, lisp/eshell/esh-io.el,
	lisp/progmodes/compile.el, lisp/progmodes/fortran.el,
	lisp/emacs-lisp/bytecomp.el, lisp/progmodes/etags.el,
	lisp/emacs-lisp/autoload.el, lisp/emacs-lisp/lisp-mnt.el,
	lisp/emacs-lisp/map-ynp.el, lisp/emacs-lisp/trace.el,
	lisp/mh-e/ChangeLog.1, lisp/mh-e/mh-acros.el,
	lisp/mh-e/mh-letter.el, lisp/mh-e/ChangeLog, lisp/mh-e/mh-alias.el,
	Makefile.in, lisp/mh-e/mh-comp.el, ChangeLog, INSTALL.CVS,
	doc/lispref/ChangeLog, leim/quail/hangul.el, lisp/mail/sendmail.el,
	lisp/mail/smtpmail.el, admin/FOR-RELEASE, lisp/url/ChangeLog,
	doc/emacs/ChangeLog, lisp/url/url-auth.el, etc/ChangeLog, etc/NEWS,
	lisp/language/hanja-util.el, lib-src/ChangeLog, doc/misc/ChangeLog,
	lisp/emulation/edt-mapper.el, lisp/textmodes/page-ext.el,
	leim/ChangeLog, nt/ChangeLog
	(lexbind.[34,12,56,6,9,66,61,84,141,204,78,30,2,10,69,30,62,10,4,58,34,57,17,105,24,8,74,31,8,9,9,93,11,55,48,20,9,69,118,48,16,16,49,25,34,22,63,15,26,40,30,10,14,15,14,13,18,51,21,225,7,26,65,80,61,99,21,37,5,53,21,34,12,11,29,18,8,9,14,39,10,39,27,20,11,66,22,13,3,16,16,21,22,18,28,28,24,13,38,25,21,31,18,40,62,20,20,5,40,32,13,139,16,6,8,29,2,2,2,17,23,76,2,15,16,13,15,2,17,18,19,21,14,15,17,46,16,94,28,70,29,28,18,13,15,9,18,14,68,22,45,34,108,13,18,13,33,33,112,70,21,19,132,177,4,81,21,14,13,59,61]):

	Merge from emacs--devo--0

	Revision: emacs@sv.gnu.org/emacs--lexbind--0--patch-89

  ...matches this change in Bazaar on the 'lexbind' branch:

    revno: 46036 [merge]
    committer: Miles Bader <miles@gnu.org>
    timestamp: Thu 2008-06-12 05:37:00 +0000
    message:
      Merge from emacs--devo--0
      
      Revision: emacs@sv.gnu.org/emacs--lexbind--0--patch-89
            [...]

* Spot-check a change.  [PASS]

  This change in CVS...

     1989-10-31 10:56  jla

	* lisp/: case-table.el (1.1), disp-table.el (1.1),
	play/dissociate.el (1.1), ehelp.el (1.1), mail/emacsbug.el (1.1),
	float-sup.el (1.1), play/gomoku.el (1.1), =gosmacs.el (1.1),
	emacs-lisp/helper.el (1.1), hexl.el (1.1), progmodes/icon.el (1.1),
	ledit.el (1.1), macros.el (1.1), mail/mail-utils.el (1.1),
	makesum.el (1.1), emulation/mlconvert.el (1.1), novice.el (1.1),
	textmodes/nroff-mode.el (1.1), textmodes/page.el (1.1),
	textmodes/paragraphs.el (1.1), rect.el (1.1), textmodes/refbib.el
	(1.1), mail/rmailedit.el (1.1), mail/rmailkwd.el (1.1),
	textmodes/spell.el (1.1), play/spook.el (1.1), tabify.el (1.1):

	Initial revision

  ...plus this change in CVS (listed separately by cvs2cl, but that's
     just an artifact of cvs2cl's commit grouping, not of CVS itself)...

      1989-10-31 10:59  jla

	* lisp/textmodes/text-mode.el (1.1), lisp/textmodes/underline.el
	(1.1), lisp/userlock.el (1.1), lisp/vms-patch.el (1.1),
	lisp/window.el (1.1), lib-src/emacstool.c (1.1):

	Initial revision

   ...plus the implicit addition of the "lisp/emacs-lisp/" directory...

   ...all together match this change in Bazaar:

      ------------------------------------------------------------
      revno: 37
      committer: Joseph Arceneaux <jla@gnu.org>
      timestamp: Tue 1989-10-31 16:00:07 +0000
      message:
        Initial revision
      added:
        lib-src/emacstool.c
        lisp/=gosmacs.el
        lisp/case-table.el
        lisp/disp-table.el
        lisp/ehelp.el
        lisp/emacs-lisp/
        lisp/emacs-lisp/helper.el
        lisp/emulation/mlconvert.el
        lisp/float-sup.el
        lisp/hexl.el
        lisp/ledit.el
        lisp/macros.el
        lisp/mail/emacsbug.el
        lisp/mail/mail-utils.el
        lisp/mail/rmailedit.el
        lisp/mail/rmailkwd.el
        lisp/makesum.el
        lisp/novice.el
        lisp/play/dissociate.el
        lisp/play/gomoku.el
        lisp/play/spook.el
        lisp/progmodes/icon.el
        lisp/rect.el
        lisp/tabify.el
        lisp/textmodes/nroff-mode.el
        lisp/textmodes/page.el
        lisp/textmodes/paragraphs.el
        lisp/textmodes/refbib.el
        lisp/textmodes/spell.el
        lisp/textmodes/text-mode.el
        lisp/textmodes/underline.el
        lisp/userlock.el
        lisp/vms-patch.el
        lisp/window.el

* Spot-check a branch-sync change.  [PASS]

  These two changes in CVS...

     2006-01-12 05:20  jhd

	* configure.in, nt/.cvsignore, nt/COPYING, nt/ChangeLog,
	nt/INSTALL, nt/README, nt/addpm.c, nt/addsection.c, nt/cmdproxy.c,
	nt/config.nt, nt/configure.bat, nt/ddeclient.c, nt/emacs.rc,
	nt/envadd.bat, nt/gmake.defs, nt/makefile.w32-in,
	nt/multi-install-info.bat, nt/nmake.defs, nt/paths.h, nt/preprep.c,
	nt/runemacs.c, nt/icons/emacs.ico, nt/icons/emacs21.ico,
	nt/inc/gettext.h, nt/inc/grp.h, nt/inc/sys/socket.h
	(XFT_JHD_BRANCH.[3,1,1,2,2,1,1,1,1,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2]):

	Update from HEAD

  ...and...

    2006-01-12 05:24  jhd

    	* .cvsignore, AUTHORS, COPYING, ChangeLog, INSTALL.CVS,
	Makefile.in, config.bat, config.guess, config.sub, configure,
        [...too many files to list here, really, hundreds of them...]

  ...match this merge commit in Bazaar on the XFT_JHD_BRANCH branch:

      [...]
      ------------------------------------------------------------
      revno: 60734 [merge]
      committer: Jan Djärv <jan.h.d@swipnet.se>
      timestamp: Thu 2006-01-12 10:25:48 +0000
      message:
        Update from HEAD
      [...]

  ....which is 40000 lines long, so I'm not including it all here.

* Spot-check revno 1.  [PASS]

  This first change in CVS...

      1985-04-17 19:48  jimb

	* lib-src/leditcfns.c (1.1, ttn-vms-21-2-B4, ttn-vms-21-2-B3,
	ttn-vms-21-2-B2, EMACS_19_34, EMACS_21_2, emacs-bidi-base,
	Boehm-GC-base, EMACS_21_3, RMAIL-MBOX-BASE, EMACS_PRETEST_21_2_95,
	EMACS_PRETEST_21_2_94, EMACS_PRETEST_21_2_93,
	EMACS_PRETEST_21_2_92, EMACS_PRETEST_21_2_91, emacs-unicode-base,
	fx-branch-base, EMACS_21_1, EMACS_21_1_BASE, patches_21_0_base,
	EMACS_PRETEST_21_0_106, EMACS_PRETEST_21_0_105,
	EMACS_PRETEST_21_0_104, EMACS_20_2, EMACS_20_4,
	EMACS_PRETEST_21_0_103, EMACS_PRETEST_21_0_102,
	EMACS_PRETEST_21_0_101, EMACS_PRETEST_21_0_100,
	EMACS_PRETEST_21_0_99, EMACS_PRETEST_21_0_98,
	EMACS_PRETEST_21_0_95, EMACS_PRETEST_21_0_93,
	EMACS_PRETEST_21_0_92, EMACS_PRETEST_21_0_91,
	EMACS_PRETEST_21_0_90):

	entered into RCS

  ...matches this first change in Bazaar (remember, all those tag
     names won't show up here):

      ------------------------------------------------------------
      revno: 1
      committer: Jim Blandy <jimb@redhat.com>
      timestamp: Thu 1985-04-18 00:48:29 +0000
      message:
        entered into RCS
      added:
        lib-src/
        lib-src/leditcfns.c

* Spot-check similar trunk and branch changes. [PASS]

  These three changes in CVS...

    2002-10-29 04:45  lektu
    	* nt/ChangeLog (1.74):
    	Added "(tiny change)" marker.
    
    2002-10-29 04:41  lektu
    	* lisp/ChangeLog (EMACS_21_1_RC.237):
    	Add "(tiny change)" markers.
    
    2002-10-29 04:38  lektu
    	* lisp/ChangeLog (1.4464):
    	Added "(tiny change)" marker.
    
   ...match these *two* changes in Bazaar:

   (on the EMACS_21_1_RC branch):
      ------------------------------------------------------------
      revno: 40805
      committer: Juanma Barranquero <lekktu@gmail.com>
      timestamp: Tue 2002-10-29 09:41:08 +0000
      message:
        Add "(tiny change)" markers.
      modified:
        lisp/ChangeLog
      
   (on the trunk branch):
      ------------------------------------------------------------
      revno: 48050
      committer: Juanma Barranquero <lekktu@gmail.com>
      timestamp: Tue 2002-10-29 09:45:19 +0000
      message:
        Added "(tiny change)" marker.
      modified:
        lisp/ChangeLog
        nt/ChangeLog

* Check that all tags are present.  [?]

  ### Get all the CVS tags.
  $ grep -E '^	[a-zA-Z0-9_-]+: [0-9.]+\.[0-9]' cvs-log.out > cvs-all-tags
  ### then filter out all the ones that are actually branches ###

  ### Get all the Bzr tags.
  $ cd emacs-bzr-repository
  $ for name in *; do (cd ${name}; bzr tags >> .../bzr-all-tags); done
  ### then uniqify them, of course ###

  ### How many are we dealing with?
  $ wc -l cvs-all-tags bzr-all-tags
  1145 cvs-all-tags
  1137 bzr-all-tags

  ### Interesting that those numbers aren't the same. ###
  ### Let's look at the diff:                         ###

  $ diff -u cvs-all-tags bzr-all-tags | grep "^[+-]"
    --- cvs-all-tags	2009-11-18 14:54:59.000000000 -0500
    +++ bzr-all-tags	2009-11-18 15:13:28.000000000 -0500
    -DAVELOVE
    +EMACS_20_1
    +EMACS_20_3
    -FLYSPELL
    -ILYA
    -mh-e-8_1
    -mh-e-8_2
    -mh-e-doc-8_1
    -mh-e-doc-8_2
    -raeburn-tag-3-for-export
    -small-dump-base
    -URL

  Regarding an earlier conversion that had a similar problem, Andreas
  said in http://article.gmane.org/gmane.emacs.devel/108751 that these
  tags were all present in the git tree.  Is that still the case?

  The two tags that are present in Bazaar but not CVS are particularly
  mystifying to me.  While 'EMACS_20_1' and 'EMACS_20_3' appear in
  'bzr tags' in trunk, they do not appear in 'cvs log' output from the
  top of the CVS tree.  I do not know where bzr got those tags from.
  Since the CVS tag (e.g.) EMACS_20_2 exists, it is reasonable to
  conclude that bzr is crazy and is getting _1 and _3 from somewhere.
  But where?

* Check that all branches are present.  [?]

  diff -u cvs-all-branches.out bzr-branches | grep "^[-+]"
  --- cvs-all-branches.out	2009-11-18 16:52:50.000000000 -0500
  +++ bzr-branches	2009-11-18 16:52:45.000000000 -0500
  +Boehm-versions
  +DAVELOVE
  +FLYSPELL
  +ILYA
  +URL
  -cedet-branch
  -emacs-unicode
  +master-UNNAMED-BRANCH
  +trunk

  Again, in http://article.gmane.org/gmane.emacs.devel/108751 Andreas
  commented that:
  
  "The emacs-unicode branch has been absorbed by the emacs-unicode-2
   branch."  

   (I'm not sure what "absorbed by the emacs-unicode-2 branch" really
   means.  The emacs-unicode branch has commits on it...  Also, what's
   up with 'cedet-branch'?  One explanation could be if a branch didn't
   have any commits then it wouldn't show up in Bazaar.  But
   'cedet-branch' has tons of commits.  )

  "The Boehm-versions branch was a short-lived branch containing only
   a gc directory.  It appears to be a mistaken checkin, the commit
   that deleted the files has the log message 'Not committed to
   branch, sorry.'."

  "The master-UNNAMED-BRANCH contains changes belonging to revisions
   that are unreachable from any branch tag.  The name was constructed
   by parsecvs since such unreferenced commits cannot exist in git.
   Actually, this branch combines several such anonymous branches, but
   parsecvs could not tell them apart."

  He also said: "The Ilya_4_35 branch appears to be the result of
  another git->bzr conversion bug.  It is an ordinary tag in git."  I
  wonder if the same applies to ILYA now?  I could find out, but I'm
  just going to send this mail now because I've been poking around in
  CVS all day and I want to share some results!

-Karl

Re: bzr repository ready?

[Chong Yidong]

Thanks for doing the checks.  The remaining issues don't seem like
problems to me; as far as I'm concerned, we can do the switch.

> Below are the results.  Mostly it's looking pretty good.  Search for
> two items where it says "[?]" to see areas where I'm concerned.
> Assuming we have good answers for those concerns, I'd say it's time to
> Just Do It.  I mean, we always have the old CVS data if worse comes to
> worst, right?

Is it possible to automatically merge changes in the bzr repository into
the CVS repository (at least for the trunk)?  Or is that too much
trouble?

Re: bzr repository ready?

[Stefan Monnier]

> Thanks for doing the checks.  The remaining issues don't seem like
> problems to me; as far as I'm concerned, we can do the switch.

Same here.  The conversion looks good.

> Is it possible to automatically merge changes in the bzr repository into
> the CVS repository (at least for the trunk)?

It would be doable, tho I don't know of any tool that would do that.

> Or is that too much trouble?

Too much trouble I think.


        Stefan

Re: bzr repository ready?

[Alan Mackenzie]

On Wed, Nov 18, 2009 at 05:29:35PM -0500, Karl Fogel wrote:
> Okay, I've spent some time yesterday and today checking over the latest
> Bzr conversion, which I obtained thusly:

>   $ scp -r kfogel@bzr.savannah.gnu.org:/srv/bzr/emacs emacs-bzr-repository

> Below are the results.  Mostly it's looking pretty good.  Search for two
> items where it says "[?]" to see areas where I'm concerned.  Assuming we
> have good answers for those concerns, I'd say it's time to Just Do It.
> I mean, we always have the old CVS data if worse comes to worst, right?

Please wait until the 23.2 pretest is out.  It's only a few more days
(?end of November?).

> -Karl

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: bzr repository ready?

[Karl Fogel]

Alan Mackenzie <acm@muc.de> writes:
> Please wait until the 23.2 pretest is out.  It's only a few more days
> (?end of November?).

Sure -- makes sense to me.

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Thu, 19 Nov 2009 00:31:20 -0500
> Cc: Andreas Schwab <schwab@linux-m68k.org>,
> 	Jason Earl <jearl@notengoamigos.org>,
> 	Ian Clatworthy <ian.clatworthy@canonical.com>, emacs-devel@gnu.org
> 
> Alan Mackenzie <acm@muc.de> writes:
> > Please wait until the 23.2 pretest is out.  It's only a few more days
> > (?end of November?).
> 
> Sure -- makes sense to me.

Also, would it be possible to publish a short ``howto'' cookbook for
those who are not familiar enough with bzr?  A DVCS has more different
workflows than CVS and its ilk, so it would be good if active
developers could know up front how to set up and how to use the
workflow that best fits their needs, without having to read lots of
unnecessary documentation and finding that out by trial and error.  At
least the following important workflows come to mind:

 . Development on the trunk -- sync with the main repository, make
   changes, submit them back to the repository.

 . Development on a release branch -- same as above, except that
   changes go to a branch.

 . Development on a public branch -- this would include more merges
   from and to the trunk, and otherwise is like the second bullet
   above.

 . Development on a private branch.

(Maybe there are more -- I have no real experience with a DVCS, so I
don't know.)

For each one of these, it would be enough to point to the relevant
sections of the existing bzr docs, no need to rewrite them, unless
some of the issues are mal-documented.

In addition, some guidelines for selecting the right version of bzr
that should be installed, and if there are more than one that's
suitable, a short list of advantages and disadvantages of each of
them.

Finally, some guidance for users on Windows, if there are any issues
that need special attention (EOL format comes to mind, as well as
binary files, but maybe there's more).

TIA

Re: bzr repository ready?

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
> Also, would it be possible to publish a short ``howto'' cookbook for
> those who are not familiar enough with bzr?  A DVCS has more different
> workflows than CVS and its ilk, so it would be good if active
> developers could know up front how to set up and how to use the
> workflow that best fits their needs, without having to read lots of
> unnecessary documentation and finding that out by trial and error.  At
> least the following important workflows come to mind:
>
>  . Development on the trunk -- sync with the main repository, make
>    changes, submit them back to the repository.
>
>  . Development on a release branch -- same as above, except that
>    changes go to a branch.
>
>  . Development on a public branch -- this would include more merges
>    from and to the trunk, and otherwise is like the second bullet
>    above.
>
>  . Development on a private branch.
>
> (Maybe there are more -- I have no real experience with a DVCS, so I
> don't know.)

My sympathies -- I came to bzr from the centralized-vc world too.  It's
actually not that hard though.  You just have to separate the concept of
"checkpoint my work" from the concept of "publish my work".  In
centralized vc, these are unified in the "commit" command.  In Bazaar,
"commit" means "checkpoint" and "push" means "publish" (roughly speaking).

I've already written http://www.emacswiki.org/emacs/BzrForEmacsDevs.
My instinct is to start with that, and then answer questions here as as
people have them, rather than write lots more text only to discover that
it doesn't answer the questions that actually come up.

> For each one of these, it would be enough to point to the relevant
> sections of the existing bzr docs, no need to rewrite them, unless
> some of the issues are mal-documented.

The above has a link to the Bazaar Users Guide, and other things.

> In addition, some guidelines for selecting the right version of bzr
> that should be installed, and if there are more than one that's
> suitable, a short list of advantages and disadvantages of each of
> them.

A version recommendation is already at the above link.

> Finally, some guidance for users on Windows, if there are any issues
> that need special attention (EOL format comes to mind, as well as
> binary files, but maybe there's more).

That I can't help with (Windows-free since 1992), but there are plenty
of Bazaar Windows users and an active user community in general.  See
http://bazaar-vcs.org/ for details.

-Karl

Re: bzr repository ready?

[Lennart Borgman]

On Fri, Nov 20, 2009 at 8:22 PM, Karl Fogel <kfogel@red-bean.com> wrote:
>
> I've already written http://www.emacswiki.org/emacs/BzrForEmacsDevs.
> My instinct is to start with that, and then answer questions here as as
> people have them, rather than write lots more text only to discover that
> it doesn't answer the questions that actually come up.


One thing I do not understand is these "lightweight" branches. Sounds
good, but where are the files?

I mean if I create a branch and it shares storage with the mirror of
the mainline, does it still have all the files there that I need to
compile and build Emacs? Is it just the history and version files that
are shared, or?

Re: bzr repository ready?

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> One thing I do not understand is these "lightweight" branches. Sounds
> good, but where are the files?
>
> I mean if I create a branch and it shares storage with the mirror of
> the mainline, does it still have all the files there that I need to
> compile and build Emacs? Is it just the history and version files that
> are shared, or?

It is essential to distinguish the working copy (aka working tree, the
files you work with) from the VC data (history, metadata, etc).

A lightweight *checkout* uses the history data that resides on the
parent branch, but you still have your working copy. It is very similar
to CVS, where you have your files but for viewing the log, diffing, etc
the repository is used.

A lightweight checkout is simply a way of saving disk space and get a
working copy quickly, as the history data is not copied from the parent
branch to the new branch.

On bzr parlance there are no lightweight branches. There are stacked
branches though, which also use the VC data of the parent branch. The
difference among a checkout and a branch is that when you commit on a
checkout your changes go to the parent branch too, but when you commit
on a branch your changes remain there, and you need another operation
(push) to send them to the parent branch (or to any other branch).

A non lightweight checkout supports committing changes without sending
them to the parent branch, using a command line option. A lightweight
checkout does not support this because it lacks the local VC data.

Actually, a non lightweight checkout is what Bazaar calls a bound
branch. You can unbind a non-ligthweigth checkout anytimme for
converting it to a regular branch and you can bind a branch to some
other branch to convert it to a checkout of that branch.

Bazaar supports quite a few models and can be confusing for those who
only know the centralized paradigm. IMHO the documentation should
recommend a model for beginners and give very detailed instructions for
it (maybe already does, I didn't read it).

For a sane version of the above explanation, execute this on your shell:

bzr help checkouts

-- 
Óscar

Re: bzr repository ready?

[Lennart Borgman]

2009/11/20 Óscar Fuentes <ofv@wanadoo.es>:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> One thing I do not understand is these "lightweight" branches. Sounds
>> good, but where are the files?
>>
>> I mean if I create a branch and it shares storage with the mirror of
>> the mainline, does it still have all the files there that I need to
>> compile and build Emacs? Is it just the history and version files that
>> are shared, or?
>
> It is essential to distinguish the working copy (aka working tree, the
> files you work with) from the VC data (history, metadata, etc).


Yes. I becames quite a bit easier to communicate when you give me the
terms to use like here.


> A lightweight *checkout* uses the history data that resides on the
> parent branch, but you still have your working copy. It is very similar
> to CVS, where you have your files but for viewing the log, diffing, etc
> the repository is used.


Ok.


> A lightweight checkout is simply a way of saving disk space and get a
> working copy quickly, as the history data is not copied from the parent
> branch to the new branch.
>
> On bzr parlance there are no lightweight branches. There are stacked
> branches though, which also use the VC data of the parent branch. The
> difference among a checkout and a branch is that when you commit on a
> checkout your changes go to the parent branch too, but when you commit
> on a branch your changes remain there, and you need another operation
> (push) to send them to the parent branch (or to any other branch).


Hm. I can see there are useful things there, but I need a bit hand holding.


Currently I have two checkouts from Emacs CVS:

* One which I just checkout and compile. I upload it if someone wants
it, but I do not use it - except for bug checking and reporting.

* The second checkout is where I have all my patches. (I have thrown
away quite a lot of them, it takes too much time to have them and if
they never makes it into Emacs I can just as well put them in the
garbage can. That saves me time at least. There are however some small
patches that are essential to get Emacs working descently.)

I never merge those changes myself into the upstream Emacs becaus I
have felt to unsure about the operations. That is a pitty of course
since it causes other people trouble, but ...

From this second checkout I build my patched version of Emacs which I
myself and many others use.


How should I set things up when using bazaar? I would really like to
somehow have my patches also in a repository an Launchpad. That would
make many things more simple.


> A non lightweight checkout supports committing changes without sending
> them to the parent branch, using a command line option. A lightweight
> checkout does not support this because it lacks the local VC data.
>
> Actually, a non lightweight checkout is what Bazaar calls a bound
> branch. You can unbind a non-ligthweigth checkout anytimme for
> converting it to a regular branch and you can bind a branch to some
> other branch to convert it to a checkout of that branch.
>
> Bazaar supports quite a few models and can be confusing for those who
> only know the centralized paradigm. IMHO the documentation should
> recommend a model for beginners and give very detailed instructions for
> it (maybe already does, I didn't read it).
>
> For a sane version of the above explanation, execute this on your shell:
>
> bzr help checkouts


... sane or insane ... it is shorter ... maybe not so much insanity then ... ;-)

But I would be glad for an example with pictures for a situation like
the one I have here.


> --
> Óscar
>
>
>
>

Re: bzr repository ready?

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Currently I have two checkouts from Emacs CVS:
>
> * One which I just checkout and compile. I upload it if someone wants
> it, but I do not use it - except for bug checking and reporting.
>
> * The second checkout is where I have all my patches. (I have thrown
> away quite a lot of them, it takes too much time to have them and if
> they never makes it into Emacs I can just as well put them in the
> garbage can. That saves me time at least. There are however some small
> patches that are essential to get Emacs working descently.)
>
> I never merge those changes myself into the upstream Emacs becaus I
> have felt to unsure about the operations. That is a pitty of course
> since it causes other people trouble, but ...
>
> From this second checkout I build my patched version of Emacs which I
> myself and many others use.
>
>
> How should I set things up when using bazaar? I would really like to
> somehow have my patches also in a repository an Launchpad. That would
> make many things more simple.

If you were starting from scratch with emacs and bazaar, you clone emacs
development branch (with `bzr branch URL' or downloading a
tarball). This way you have a branch which is your local mirror of
emacs' development and acts as the basis for your experiments.

You are interested on a personal variation of emacs' sources. For this
you clone your local mirror and incorporate your changes, one at a time,
on the new branch. The net effect is as if you were using your own,
private, emacs CVS *repository* which as rich as the GNU one. From time
to time you merge in the changes from the GNU development branch, for
keeping your personal emacs up to date. Finally, you can publish your
personalized emacs branch either directly, from your own machine, or
with some service like launchpad.

The advantage over your actual CVS setup is that you are using the full
capabilities of a VC system for your own convenience, with history,
etc. People can see which changes you made your emacs variation the same
way they can see the changes the rest of developers do to the GNU
branch. This opens a lot of new possibilites. For instance, if I were
tracking the official emacs development, I could create my private
mirror and incorporate specific changes from your branch.

BTW, did you see the e-mail I wrote to you a few days ago asking for the
patch that fixes the maximized frame bug? If we were using bzr right
now, I could locate and incorporate the change on my own emacs branch.

-- 
Óscar

Re: bzr repository ready?

[Stefan Monnier]

> If you were starting from scratch with emacs and bazaar, you clone emacs
> development branch (with `bzr branch URL' or downloading a
> tarball).

Actually, "bzr branch URL" on the Emacs repository is a bad idea.
In his setup where he'll be using 2 branches, he wants to use
a shared repository.


        Stefan

Re: bzr repository ready?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If you were starting from scratch with emacs and bazaar, you clone emacs
>> development branch (with `bzr branch URL' or downloading a
>> tarball).
>
> Actually, "bzr branch URL" on the Emacs repository is a bad idea.
> In his setup where he'll be using 2 branches, he wants to use
> a shared repository.

You got that wrong. I was not suggesting that he shall create a remote
branch. `bzr branch URL' creates a local branch:

bzr branch http://somehost.com/repo/bzr/project/trunk

creates a branch which is a clone of the branch pointed by the URL, but
on your local machine.

Besides, using a shared repository is just a disk&time saving trick, it
doesn't affect the workflow otherwise.

So he needs to download the Emacs branch. `bzr branch URL' is one way,
downloading a tarball is another. You can put the result of `bzr branch'
directly on a shared repo. If you downloaded the tarball and want to put
your mirror branch on a shared repository you need two extra steps
besides downloading and untarring. The first is precisely `bzr branch',
but this time locally using the tarball'ed branch as the parent, and the
second step is configuring the resulting branch for using the remote
emacs branch at GNU as its parent.

Once you created your local mirror with any of the methods above
mentioned, you can start making local branches for hacking, for
storing your personal changes, or for publishing them.

-- 
Óscar Fuentes
Desarrollo de Software

Re: bzr repository ready?

[Karl Fogel]

Everyone:

It's a wiki.  Please edit it :-).  

I've always expected that doc would need updating after we start using
Bazaar for development; if we can make some of those improvements before
then, that's even better.  (I'm no Bazaar expert, so please don't worry
that you'll be losing some deep wisdom if you edit it -- what I wrote is
just a starting point.)

-Karl

Óscar Fuentes <ofv@wanadoo.es> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> If you were starting from scratch with emacs and bazaar, you clone emacs
>>> development branch (with `bzr branch URL' or downloading a
>>> tarball).
>>
>> Actually, "bzr branch URL" on the Emacs repository is a bad idea.
>> In his setup where he'll be using 2 branches, he wants to use
>> a shared repository.
>
> You got that wrong. I was not suggesting that he shall create a remote
> branch. `bzr branch URL' creates a local branch:
>
> bzr branch http://somehost.com/repo/bzr/project/trunk
>
> creates a branch which is a clone of the branch pointed by the URL, but
> on your local machine.
>
> Besides, using a shared repository is just a disk&time saving trick, it
> doesn't affect the workflow otherwise.
>
> So he needs to download the Emacs branch. `bzr branch URL' is one way,
> downloading a tarball is another. You can put the result of `bzr branch'
> directly on a shared repo. If you downloaded the tarball and want to put
> your mirror branch on a shared repository you need two extra steps
> besides downloading and untarring. The first is precisely `bzr branch',
> but this time locally using the tarball'ed branch as the parent, and the
> second step is configuring the resulting branch for using the remote
> emacs branch at GNU as its parent.
>
> Once you created your local mirror with any of the methods above
> mentioned, you can start making local branches for hacking, for
> storing your personal changes, or for publishing them.

Re: bzr repository ready?

[Stephen J. Turnbull]

Karl Fogel writes:

 > Everyone:
 > 
 > It's a wiki.  Please edit it :-).  

OK, I've done so :-).  Please review my work, though; I'm far more
expert on git and VCS theory than I am on bzr pragmatics.

Specifically, one small change was I glossed the difference between
the "dev" branch (one branch for sequences of small independent
changes), vs. the SOME-TASKNAME branch (of which there will be many,
each containing a set of related commits).  For example, typically you
would delete a feature branch, but hang on to and reuse the "'dev"
branch.

The more important one is that AIUI, pushing directly from
SOME-TASKNAME is a bad idea.  Typically, you want to merge that branch
into trunk (the mirror branch), then commit (which automatically
pushes to upstream in the recommended setup as a bound branch).

The reason is that you want something like this, which is how Bazaar
will present the merge and commit workflow:

$ bzr log
3 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
2 Merge concurrent development
1 Parent of SOME-TASKNAME
$ bzr log -n 0
3 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
  3.3 Munge a bunch of fiddly little bits, all alike
  3.2 Merge from trunk
  3.1 Munge a fiddly little bunch of bits, all alike
2 Merge concurrent development
  2.1 One big ol commit
1 Parent of SOME-TASKNAME
  [several hundred thousand fiddly commits elided]

Not this, which is how Bazaar will present the "just push" workflow:

$ bzr log
5 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
4 Munge a bunch of fiddly little bits, all alike
3 Merge from trunk
2 Munge a fiddly little bunch of bits, all alike
1 Parent of SOME-TASKNAME
$ bzr log -n 0
5 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
4 Munge a bunch of fiddly little bits, all alike
3 Merge from trunk
  3.1 Merge concurrent development
    3.1.1 One big ol commit
2 Munge a fiddly little bunch of bits, all alike
1 Parent of SOME-TASKNAME
  [several hundred thousand fiddly commits elided]

Note how the latter inflates the importance of individual commits from
SOME-TASKNAME, while confusing the timing with which various commits
landed on the trunk.  (I'm not sure I got the above exactly right, but
such effects are definitely part of the way bzr log looks at the
branch's history.)

Re: bzr repository ready?

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Karl Fogel writes:
>
>  > Everyone:
>  > 
>  > It's a wiki.  Please edit it :-).  
>
> OK, I've done so :-).  Please review my work, though; I'm far more
> expert on git and VCS theory than I am on bzr pragmatics.
>
> Specifically, one small change was I glossed the difference between
> the "dev" branch (one branch for sequences of small independent
> changes), vs. the SOME-TASKNAME branch (of which there will be many,
> each containing a set of related commits).  For example, typically you
> would delete a feature branch, but hang on to and reuse the "'dev"
> branch.
>
> The more important one is that AIUI, pushing directly from
> SOME-TASKNAME is a bad idea.  Typically, you want to merge that branch
> into trunk (the mirror branch), then commit (which automatically
> pushes to upstream in the recommended setup as a bound branch).

So just to make sure, when you wrote in the wiki

  "You can also just push it directly to the upstream master:
      bzr push bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk/"

you were talking about running that from within branch SOME-TASKNAME,
*not* from within the local trunk mirror, right?

(It might be good to always wrap commands in 'cd foo; ...; cd ..' so the
reader is absolutely clear on what's taking place where.)

Right below that, I tweaked the explanation a bit; please review and see
what you think.  There is one sentence that still puzzles me; it now
reads:

  "On the other hand, if you push directly from the ##SOME-TASKNAME##
   branch, your branch will be perceived as part of the mainline by
   ##bzr log##, while commits on the mainline (including merges from
   other developers and their detailed branch histories) will be hidden."

I don't understand the second part.  How will commits on the mainline be
hidden?  (That is, from whom will they be hidden, and in what situations?)

> The reason is that you want something like this, which is how Bazaar
> will present the merge and commit workflow:
>
> $ bzr log
> 3 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
> 2 Merge concurrent development
> 1 Parent of SOME-TASKNAME
> $ bzr log -n 0
> 3 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
>   3.3 Munge a bunch of fiddly little bits, all alike
>   3.2 Merge from trunk
>   3.1 Munge a fiddly little bunch of bits, all alike
> 2 Merge concurrent development
>   2.1 One big ol commit
> 1 Parent of SOME-TASKNAME
>   [several hundred thousand fiddly commits elided]
>
> Not this, which is how Bazaar will present the "just push" workflow:
>
> $ bzr log
> 5 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
> 4 Munge a bunch of fiddly little bits, all alike
> 3 Merge from trunk
> 2 Munge a fiddly little bunch of bits, all alike
> 1 Parent of SOME-TASKNAME
> $ bzr log -n 0
> 5 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
> 4 Munge a bunch of fiddly little bits, all alike
> 3 Merge from trunk
>   3.1 Merge concurrent development
>     3.1.1 One big ol commit
> 2 Munge a fiddly little bunch of bits, all alike
> 1 Parent of SOME-TASKNAME
>   [several hundred thousand fiddly commits elided]
>
> Note how the latter inflates the importance of individual commits from
> SOME-TASKNAME, while confusing the timing with which various commits
> landed on the trunk.  (I'm not sure I got the above exactly right, but
> such effects are definitely part of the way bzr log looks at the
> branch's history.)

Agreed.

It might be better just to recommend the merge-and-commit workflow for
*everything*, always, and let those who want to become Bzr Jedi Masters
learn to do the "just push" on their own, when they are experienced
enough to understand the consequences.  Thoughts?

-Karl

Re: bzr repository ready?

[Stephen J. Turnbull]

Karl Fogel writes:

 > So just to make sure, when you wrote in the wiki

I've reviewed your changes to the wiki entry and they are absolutely
correct.

 >   "You can also just push it directly to the upstream master:
 >       bzr push bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk/"
 > 
 > you were talking about running that from within branch SOME-TASKNAME,
 > *not* from within the local trunk mirror, right?

Yes.

 > (It might be good to always wrap commands in 'cd foo; ...; cd ..' so the
 > reader is absolutely clear on what's taking place where.)

Hey, by the time I finished that entry it was 4 am....  I think I done
purty good.<wink>  But yes, your convention makes a lot of sense (note
that I did get it right in my workflow response to somebody, later).

 >   "On the other hand, if you push directly from the ##SOME-TASKNAME##
 >    branch, your branch will be perceived as part of the mainline by
 >    ##bzr log##, while commits on the mainline (including merges from
 >    other developers and their detailed branch histories) will be hidden."
 > 
 > I don't understand the second part.  How will commits on the mainline be
 > hidden?  (That is, from whom will they be hidden, and in what
 > situations?)

They will be hidden from "bzr log -n1" on the master repository, when
they are brought in to SOME-TASKNAME via merges from the master
(upstream) or trunk (local mirror).  The reason is that when you merge
into SOME-TASKNAME from one of those, the commit from SOME-TASKNAME is
the *left parent* of the merge commit.  When you push that merge
commit to master, it will become the tip *as is*, and thus all work
committed to the master since SOME-TASKNAME branched will be on
rightward branches, and will be summarized as merges into SOME-TASKNAME.

 > It might be better just to recommend the merge-and-commit workflow for
 > *everything*, always, and let those who want to become Bzr Jedi Masters
 > learn to do the "just push" on their own, when they are experienced
 > enough to understand the consequences.  Thoughts?

I agree about the recommendation, but think description of the effects
should be moved to a separate page (or an explanatory section if
there's a possibility that this page might move to bazaar-vcs).  It's
too easy to discover for yourself, so I would write something like

    It might occur to you to save some effort by doing "bzr push" from
    the SOME-TASKNAME branch.  *Do not do this*: it `results in a
    different history`__ in the upstream master.

    __BzrLogTreatsLeftmostParentsDifferentlyFromRightwardParents

(markup is reStructuredText).  The linked page would contain the full
explanation.

Re: bzr repository ready?

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Hey, by the time I finished that entry it was 4 am....  I think I done
> purty good.<wink>  

You did, you did!  <pat> <pat>  :-)

>  > I don't understand the second part.  How will commits on the mainline be
>  > hidden?  (That is, from whom will they be hidden, and in what
>  > situations?)
>
> They will be hidden from "bzr log -n1" on the master repository, when
> they are brought in to SOME-TASKNAME via merges from the master
> (upstream) or trunk (local mirror).  The reason is that when you merge
> into SOME-TASKNAME from one of those, the commit from SOME-TASKNAME is
> the *left parent* of the merge commit.  When you push that merge
> commit to master, it will become the tip *as is*, and thus all work
> committed to the master since SOME-TASKNAME branched will be on
> rightward branches, and will be summarized as merges into SOME-TASKNAME.

Whooo... okay, I see, right.  So, how shall we summarize that in a
parenthetical aside?  

(Rhetorical question.  I agree with your suggestion below that we're
better off just recommending against that workflow.)

>  > It might be better just to recommend the merge-and-commit workflow for
>  > *everything*, always, and let those who want to become Bzr Jedi Masters
>  > learn to do the "just push" on their own, when they are experienced
>  > enough to understand the consequences.  Thoughts?
>
> I agree about the recommendation, but think description of the effects
> should be moved to a separate page (or an explanatory section if
> there's a possibility that this page might move to bazaar-vcs).  It's
> too easy to discover for yourself, so I would write something like
>
>     It might occur to you to save some effort by doing "bzr push" from
>     the SOME-TASKNAME branch.  *Do not do this*: it `results in a
>     different history`__ in the upstream master.
>
>     __BzrLogTreatsLeftmostParentsDifferentlyFromRightwardParents
>
> (markup is reStructuredText).  The linked page would contain the full
> explanation.

I completely agree.  We might even find a place in the existing generic
Bazaar documentation we can point to, for some of these effects.

It's late in Chicago now and I won't have a chance to make this edit
before I sleep.  If you get a chance, please go ahead and do it;
otherwise I'll try to update the doc later.

-Karl

Re: bzr repository ready?

[Karl Fogel]

Karl Fogel <kfogel@red-bean.com> writes:
> It's late in Chicago now and I won't have a chance to make this edit
> before I sleep.  If you get a chance, please go ahead and do it;
> otherwise I'll try to update the doc later.

Okay, I've done this now.  I just linked directly to your mail (in the
archives) for the explanation, as I couldn't find a one in the regular
Bazaar docs and didn't want to create a new page just for that.

-Karl

Re: bzr repository ready?

[Stephen J. Turnbull]

Karl Fogel writes:

 > Okay, I've done this now.  I just linked directly to your mail (in the
 > archives) for the explanation, as I couldn't find a one in the regular
 > Bazaar docs and didn't want to create a new page just for that.

Urk.  I just overwrote it with mine (plus a major reorganization :-þ)
... fortunately, the wiki gave me a diff (yours was more concise and
better :-).

Hope you like the new layout. :-)

Re: bzr repository ready?

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > Okay, I've done this now.  I just linked directly to your mail (in the
>  > archives) for the explanation, as I couldn't find a one in the regular
>  > Bazaar docs and didn't want to create a new page just for that.
>
> Urk.  I just overwrote it with mine (plus a major reorganization :-þ)
> ... fortunately, the wiki gave me a diff (yours was more concise and
> better :-).
>
> Hope you like the new layout. :-)

Wow -- it's a complete rewrite, and IMHO a vast improvement.

I have only a few tweaks to make (stray paren here, list style there),
and will make them, but basically I think this is terrific, and that
people should start reading it now.  Thank you!

Re: bzr repository ready?

[Karl Fogel]

Karl Fogel <kfogel@red-bean.com> writes:
> I have only a few tweaks to make (stray paren here, list style there),
> and will make them, but basically I think this is terrific, and that
> people should start reading it now.  Thank you!

Okay, done.  My changes were a bit more extensive than I expected,
though they were not deep.  Please review if you get a chance!

-Karl

Re: bzr repository ready?

[Stephen J. Turnbull]

Karl Fogel writes:

 > Okay, done.  My changes were a bit more extensive than I expected,
 > though they were not deep.  Please review if you get a chance!

Looks good.  The only thing I question is the cite in the introduction
to Bazaar's Bazaar for CVS Users.  The concrete workflow presented
there (ie, with actual bzr command examples) is the one Oscar
recommends, but it's mixed in with a huge amount of extra stuff *plus*
a whole set of workflows that simply cannot be accomplished with the
concrete setup described.  Cf. the comment I just added in the
reference section at the end.  It used to be "a brief stub".  Now it's

    A whirlwind introduction to the features and command-line UI of
    Bazaar. The workflow described is very similar to that of
    BzrQuickStartForEmacsDevs, and the latter document may be easier
    to understand because it concentrates on introducing the workflow
    rather than the while field of distributed version control.

Do you agree with that?  If you do, I'll fix it to have an internal
link to References (where the annotation is, and belongs) rather than
a direct link to the document itself.  If not, feel free to fix it or
give me a word of guidance and I'll do it.

Re: bzr repository ready?

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Looks good.  The only thing I question is the cite in the introduction
> to Bazaar's Bazaar for CVS Users.  The concrete workflow presented
> there (ie, with actual bzr command examples) is the one Oscar
> recommends, but it's mixed in with a huge amount of extra stuff *plus*
> a whole set of workflows that simply cannot be accomplished with the
> concrete setup described.  Cf. the comment I just added in the
> reference section at the end.  It used to be "a brief stub".  Now it's
>
>     A whirlwind introduction to the features and command-line UI of
>     Bazaar. The workflow described is very similar to that of
>     BzrQuickStartForEmacsDevs, and the latter document may be easier
>     to understand because it concentrates on introducing the workflow
>     rather than the while field of distributed version control.
>
> Do you agree with that?  If you do, I'll fix it to have an internal
> link to References (where the annotation is, and belongs) rather than
> a direct link to the document itself.  If not, feel free to fix it or
> give me a word of guidance and I'll do it.

Yes, I agree.  Note I've edited BzrForEmacsDevs heavily since you posted
the above, but I think what you say still applies.

Re: bzr repository ready?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Sat, 21 Nov 2009 06:34:21 +0100
> 
> You got that wrong. I was not suggesting that he shall create a remote
> branch. `bzr branch URL' creates a local branch:
> 
> bzr branch http://somehost.com/repo/bzr/project/trunk
> 
> creates a branch which is a clone of the branch pointed by the URL, but
> on your local machine.
> 
> Besides, using a shared repository is just a disk&time saving trick, it
> doesn't affect the workflow otherwise.

So when to use a shared repository and when not?  Could you please
give some details that would allow one to make up her mind?

> So he needs to download the Emacs branch. `bzr branch URL' is one way,
> downloading a tarball is another. You can put the result of `bzr branch'
> directly on a shared repo.

What does the last sentence mean, in terms of commands that I would
need to issue?

> If you downloaded the tarball and want to put
> your mirror branch on a shared repository you need two extra steps
> besides downloading and untarring. The first is precisely `bzr branch',
> but this time locally using the tarball'ed branch as the parent, and the
> second step is configuring the resulting branch for using the remote
> emacs branch at GNU as its parent.

Again, please tell more details.  Showing the commands or pointing to
the bzr docs would be a good start.  Without some additional info, all
this sounds to me like a conversation in a language I don't
understand.  Please try to make it more understandable for someone who
does not have your level of knowledge and experience with bzr, but
needs nonetheless to make up her mind about the way to set up and use
bzr without wasting too much time.  Thanks in advance.

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > Óscar Fuentes <ofv@wanadoo.es> writes:

 > > Besides, using a shared repository is just a disk&time saving trick, it
 > > doesn't affect the workflow otherwise.

N.B.  This is false, even today.  Bazaar now supports commands for
interrogating the shared repository.  The most important in daily use
is "branches", which lists the branches currently available from that
repository.

 > So when to use a shared repository and when not?

(Core) Emacs developers will always want to use a shared repository.
The penalty for using one for even a single branch is very small; as
soon as you have more than one, time and disk savings build rapidly.

The *only* times one wants to *avoid* use of a shared repository are
(1) for casually browsing the source and related contributions (eg, you
    occasionally have one-line fixes), you plan to send patches to
    the developers for them, and you expect *never* to participate
    actively in project development;
(2) when the project wishes to *enforce* a centralized workflow on the
    developers.

Many important enhancements to bzr (like the "pipeline" add-on, which
helps to manage a "stack" of patches, like Andrew Morton's famous
"quilt" script) depend on "cheap branching", which shared repositories
provide.  I'm not going to go into details here, because you may not
ever need those (and there are often alternatives), but having the
shared repository available from the start makes life much more
pleasant in many such scenarios.

Re: bzr repository ready?

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Eli Zaretskii writes:
>  > Óscar Fuentes <ofv@wanadoo.es> writes:
>
>  > > Besides, using a shared repository is just a disk&time saving trick, it
>  > > doesn't affect the workflow otherwise.
>
> N.B.  This is false, even today.  Bazaar now supports commands for
> interrogating the shared repository.  The most important in daily use
> is "branches", which lists the branches currently available from that
> repository.

What you say is correct from the POV of a bzr sever. From the POV of the
hacker it is irrelevant. If you are working on your dev machine, a `ls
path' is more handy than `bzr branches path'.

[snip]

-- 
Óscar

Re: bzr repository ready?

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > What you say is correct from the POV of a bzr sever. From the POV of the
 > hacker it is irrelevant. If you are working on your dev machine, a `ls
 > path' is more handy than `bzr branches path'.

But "bzr branches" is even more handy than either, since it doesn't
require the argument.  I believe the Bazaar Explorer also uses "bzr
branches" for this purpose.

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> You got that wrong. I was not suggesting that he shall create a remote
>> branch. `bzr branch URL' creates a local branch:
>> 
>> bzr branch http://somehost.com/repo/bzr/project/trunk
>> 
>> creates a branch which is a clone of the branch pointed by the URL, but
>> on your local machine.
>> 
>> Besides, using a shared repository is just a disk&time saving trick, it
>> doesn't affect the workflow otherwise.
>
> So when to use a shared repository and when not?  Could you please
> give some details that would allow one to make up her mind?

As shared repositories saves disk space and speeds up branch creation,
it is advisable to use them. Of course, a shared repo imposes that the
branches shall be on a certain, fixed location on your filesystem
hierarchy (i.e. within the directory that contains the shared repo). It
is not good idea to move branches around when they reside on a shared
repo (as other branches may contain internal pointers to them). I don't
think this is a problem for most users, though.

>> So he needs to download the Emacs branch. `bzr branch URL' is one way,
>> downloading a tarball is another. You can put the result of `bzr branch'
>> directly on a shared repo.
>
> What does the last sentence mean, in terms of commands that I would
> need to issue?

# Create a shared repo on a directory named `emacs-dev':
bzr init-repo emacs-dev
cd emacs-dev
# Now create our own mirror of the emacs master development branch:
bzr branch URL-TO-EMACS-DEV-BRANCH-ON-GNU mirror

From now on, within the same `emacs-dev' directory, you use `bzr branch'
again for creating branches for hacking, etc.

bzr branch mirror my-sandbox

>> If you downloaded the tarball and want to put
>> your mirror branch on a shared repository you need two extra steps
>> besides downloading and untarring. The first is precisely `bzr branch',
>> but this time locally using the tarball'ed branch as the parent, and the
>> second step is configuring the resulting branch for using the remote
>> emacs branch at GNU as its parent.
>
> Again, please tell more details.  Showing the commands or pointing to
> the bzr docs would be a good start.  Without some additional info, all
> this sounds to me like a conversation in a language I don't
> understand.  Please try to make it more understandable for someone who
> does not have your level of knowledge and experience with bzr, but
> needs nonetheless to make up her mind about the way to set up and use
> bzr without wasting too much time.  Thanks in advance.

A branch is self contained. This means that it really doesn't matter
much if you obtain your mirror branch directly from GNU or from any
other mirror of the GNU master branch.

By downloading and untarring a tarball with a copy of the GNU master
branch, you alreday did the equivalent of `bzr branch
URL-TO-GNU-MASTER-BRANCH'. However, that branch does not reside on a
shared repo and, AFAIK, it is not right to move the directory where your
untarred branch resides to the directory of a bzr shared repo.

The solution is to `bzr branch' your untarred branch to the shared repo:

# Let's suppose that your untarred branch is on emacs-untarred/
# We start by creating a shared repo:
bzr init-repo emacs-dev
# Now we branch (i.e. clone) the untarred branch to our shared repo:
cd emacs-dev
bzr branch ../emacs-untarred mirror
# That's it. We can remove the untarred branch.
# As the tarball may be a bit out of date, we get now the most recent
# changes:
cd mirror
bzr update

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 21 Nov 2009 00:05:41 -0500
> Cc: Lennart Borgman <lennart.borgman@gmail.com>, emacs-devel@gnu.org
> 
> > If you were starting from scratch with emacs and bazaar, you clone emacs
> > development branch (with `bzr branch URL' or downloading a
> > tarball).
> 
> Actually, "bzr branch URL" on the Emacs repository is a bad idea.

Why is that a bad idea?

Re: bzr repository ready?

[Eli Zaretskii]

> X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,
> 	UNPARSEABLE_RELAY autolearn=unavailable version=3.1.0
> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 20 Nov 2009 23:46:08 +0100
> Cc: Lennart Borgman <lennart.borgman@gmail.com>
> 
> Finally, you can publish your personalized emacs branch either
> directly, from your own machine, or with some service like
> launchpad.

If this is an important part of the workflow we want to have, then the
wiki should describe how to do that.  (Maybe I'm wrong, but this
ability to publish local branches without having them on the master
repository is the only feature of a dVCS that really makes a
difference; everything else can be emulated with CVS.  But please do
not start an argument over this, as it's really not important whether
I'm wrong here.)

Re: bzr repository ready?

[Karl Fogel]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Bazaar supports quite a few models and can be confusing for those who
> only know the centralized paradigm. IMHO the documentation should
> recommend a model for beginners and give very detailed instructions for
> it (maybe already does, I didn't read it).

It does.  See

  http://www.emacswiki.org/emacs/BzrForEmacsDevs#RegularContributors

(I'm sure it could be improved, of course.)

-Karl

Re: bzr repository ready?

[Óscar Fuentes]

Hello Karl.

Karl Fogel <kfogel@red-bean.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> Bazaar supports quite a few models and can be confusing for those who
>> only know the centralized paradigm. IMHO the documentation should
>> recommend a model for beginners and give very detailed instructions for
>> it (maybe already does, I didn't read it).
>
> It does.  See
>
>   http://www.emacswiki.org/emacs/BzrForEmacsDevs#RegularContributors
>
> (I'm sure it could be improved, of course.)

Some random comments.

For large compiled projects such as Emacs, the use of feature branches
is not that great. First, building takes a long time. Second, it imposes
a large penalty on those who just want to hack some elisp. On my private
work I'm on a similar scenario and don't know how to solve this. Maybe a
system based on `bzr switch' is the solution for Emacs, although it is
not so simple to understand as feature branches. For the diehard CVS
users, beginning with a single work branch is the solution. `bzr shelve'
would help them, but if you are going to explain all that on the emacs
wiki page, maybe better write the most simplistic guide about getting a
working copy of Emacs and direct them to bazaar's GettingStarted.

The document says:

If you’re one of the Emacs maintainers, then you can just push it directly to the upstream master:
      bzr push %%bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk/%%

(what about the % symbols?)

it is worth noting that bzr can remember a default location for push,
pull, etc. So maybe something like this:

If you’re one of the Emacs maintainers, then you can just push it directly to the upstream master:
      bzr push --remember bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk/
The next time bzr will remember the URL and you will need only
      bzr push

Maybe `bzr info` is worth some attention too.

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Sat, 21 Nov 2009 01:53:44 +0100
> 
> For large compiled projects such as Emacs, the use of feature branches
> is not that great. First, building takes a long time.

Why does the building take a long time in that case?

> Second, it imposes a large penalty on those who just want to hack
> some elisp.

What penalty is that?

> Maybe a system based on `bzr switch' is the solution for Emacs,
> although it is not so simple to understand as feature branches. For
> the diehard CVS users, beginning with a single work branch is the
> solution. `bzr shelve' would help them

I'd appreciate some more details on that.  It's hard to make up your
mind about the usage patterns with so many new factors being
introduced in ever sentence without any explanations.  (And yes, I did
read the Bazaar User Reference for these two commands, but it's just
awful: "bzr shelve" does not describe its argument FILE, "bzr switch"
does not tell what is its argument TO_LOCATION, etc.  The User Guide
helps a bit, but you cannot search in it, at least not in the on-line
version.)

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> For large compiled projects such as Emacs, the use of feature branches
>> is not that great. First, building takes a long time.
>
> Why does the building take a long time in that case?
>
>> Second, it imposes a large penalty on those who just want to hack
>> some elisp.
>
> What penalty is that?

Let's suppose that you want to do some lightweight hacking on a elisp
component of emacs. The `feature branch' workflow says that you create a
new local branch specifically for that:

bzr branch path/to/my/local/emacs/mirror fix-bug-3429

and then you edit the .el files. But at some point you want to test
them, and for that you need an emacs executable. Now, building emacs is
not a fast operation even on a GNU/Linux modern desktop (let's not
mention Windows). Hence, even when you start the build right after the
feature branch creation, it is possible that you end your modifications
before the build ends. This certainly will occur often on slow GNU/Linux
machines and even on fast Windows machines.

Maybe emacs has a mechanism for executing it using a uncompiled elisp
source tree that resides on other directory. If that is the case, you
could use a pre-existent emacs executable for testing your changes.

>> Maybe a system based on `bzr switch' is the solution for Emacs,
>> although it is not so simple to understand as feature branches. For
>> the diehard CVS users, beginning with a single work branch is the
>> solution. `bzr shelve' would help them
>
> I'd appreciate some more details on that.  It's hard to make up your
> mind about the usage patterns with so many new factors being
> introduced in ever sentence without any explanations.  (And yes, I did
> read the Bazaar User Reference for these two commands, but it's just
> awful: "bzr shelve" does not describe its argument FILE, "bzr switch"
> does not tell what is its argument TO_LOCATION, etc.  The User Guide
> helps a bit, but you cannot search in it, at least not in the on-line
> version.)

I guess that this is yet another case of "having lots of options is
counter-producing for the uninformed".

I was thinking on writing an incremental guide for those who know
nothing about DVCSs and bzr in particular, beginning with the most
simple workflows and evolving step by step to the sophisticated ones,
explaining the advantages that each level brings over the previous
one. This way each hacker could choose his own workflow basing the
decission on some solid info. But my English is awful. If I could write
on Spanish and some volunteer translate it to English...

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Sat, 21 Nov 2009 17:45:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> For large compiled projects such as Emacs, the use of feature branches
> >> is not that great. First, building takes a long time.
> >
> > Why does the building take a long time in that case?
> >
> >> Second, it imposes a large penalty on those who just want to hack
> >> some elisp.
> >
> > What penalty is that?
> 
> Let's suppose that you want to do some lightweight hacking on a elisp
> component of emacs. The `feature branch' workflow says that you create a
> new local branch specifically for that:
> 
> bzr branch path/to/my/local/emacs/mirror fix-bug-3429
> 
> and then you edit the .el files. But at some point you want to test
> them, and for that you need an emacs executable. Now, building emacs is
> not a fast operation even on a GNU/Linux modern desktop (let's not
> mention Windows). Hence, even when you start the build right after the
> feature branch creation, it is possible that you end your modifications
> before the build ends. This certainly will occur often on slow GNU/Linux
> machines and even on fast Windows machines.

I'm not quite sure I understand.  Are you talking about bootstrap?
That one indeed can take 30 minutes on Windows.  But that's a one-time
thing; subsequent builds, when just a handful of files are modified
are much faster.  It's a rare feature or even a bugfix that needs only
one build.  And its already clear that making a full-fledged branch
for a simple bugfix is not the best idea.

> I guess that this is yet another case of "having lots of options is
> counter-producing for the uninformed".

Not if the information is presented in a clear way that is relevant
for the context in which it is required (in this case, Emacs
development).

Actually, I think I've understood enough to know what to do first when
we switch to bzr.  About the only thing that's still not clear enough
is whether to keep my bidi branch locally or on subversions.  Any
thoughts?

> But my English is awful.

There's nothing wrong, let alone awful, with your English.  Thanks
a lot for taking time to explain all this.

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> For large compiled projects such as Emacs, the use of feature branches
>> >> is not that great. First, building takes a long time.
>> >
>> > Why does the building take a long time in that case?
>> >
>> >> Second, it imposes a large penalty on those who just want to hack
>> >> some elisp.
>> >
>> > What penalty is that?
>> 
>> Let's suppose that you want to do some lightweight hacking on a elisp
>> component of emacs. The `feature branch' workflow says that you create a
>> new local branch specifically for that:
>> 
>> bzr branch path/to/my/local/emacs/mirror fix-bug-3429
>> 
>> and then you edit the .el files. But at some point you want to test
>> them, and for that you need an emacs executable. Now, building emacs is
>> not a fast operation even on a GNU/Linux modern desktop (let's not
>> mention Windows). Hence, even when you start the build right after the
>> feature branch creation, it is possible that you end your modifications
>> before the build ends. This certainly will occur often on slow GNU/Linux
>> machines and even on fast Windows machines.
>
> I'm not quite sure I understand.  Are you talking about bootstrap?
> That one indeed can take 30 minutes on Windows.  But that's a one-time
> thing; subsequent builds, when just a handful of files are modified
> are much faster.  It's a rare feature or even a bugfix that needs only
> one build. 

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.

> And its already clear that making a full-fledged branch for a simple
> bugfix is not the best idea.

IMO, yes, but other DVCS proponents will try to convince you that
creating feature branches even for simple changes is the Right
Thing. And that is true if your project doesn't require building before
testing.

[snip]

> Actually, I think I've understood enough to know what to do first when
> we switch to bzr.  About the only thing that's still not clear enough
> is whether to keep my bidi branch locally or on subversions.  Any
> thoughts?

Precisely DVCS shines on cases like yours: you have your own private
branch were you develop bidi and, besides synching with emacs' master
branch from time to time, you occasionally push your changes to a
publicly availabe mirror of your bidi branch, so people can follow your
development and hopefully test it and contribute patches.

DVCS makes this very easy, either using your own machine as the server
(a http server suffices for read-only access) or a service like
launchpad, which adds bug reporting, patch management, etc.

If you need help on figuring out how to do that, please ask. How do you
manage your bidi branch right now? Is it a CVS branch on the Emacs
repository or a set of patches that you store on your machine?

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 Nov 2009 21:17:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >> For large compiled projects such as Emacs, the use of feature branches
> >> >> is not that great. First, building takes a long time.
> >> >
> >> > Why does the building take a long time in that case?
> >> >
> >> >> Second, it imposes a large penalty on those who just want to hack
> >> >> some elisp.
> >> >
> >> > What penalty is that?
> >> 
> >> Let's suppose that you want to do some lightweight hacking on a elisp
> >> component of emacs. The `feature branch' workflow says that you create a
> >> new local branch specifically for that:
> >> 
> >> bzr branch path/to/my/local/emacs/mirror fix-bug-3429
> >> 
> >> and then you edit the .el files. But at some point you want to test
> >> them, and for that you need an emacs executable. Now, building emacs is
> >> not a fast operation even on a GNU/Linux modern desktop (let's not
> >> mention Windows). Hence, even when you start the build right after the
> >> feature branch creation, it is possible that you end your modifications
> >> before the build ends. This certainly will occur often on slow GNU/Linux
> >> machines and even on fast Windows machines.
> >
> > I'm not quite sure I understand.  Are you talking about bootstrap?
> > That one indeed can take 30 minutes on Windows.  But that's a one-time
> > thing; subsequent builds, when just a handful of files are modified
> > are much faster.  It's a rare feature or even a bugfix that needs only
> > one build. 
> 
> 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.

> How do you manage your bidi branch right now? Is it a CVS branch on
> the Emacs repository or a set of patches that you store on your
> machine?

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.

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> How do you manage your bidi branch right now? Is it a CVS branch on
>> the Emacs repository or a set of patches that you store on your
>> machine?
>
> 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.

First, you are not using a version control system for your changes: it
would be quite scary to me making large changes to a complex code base
without the ability to undo the changes or inspect how and when they
were introduced. Second, publishing your work requires making a tarball
with the modified sources (or the diff against certain tag of Emacs
CVS).

Using bzr will bring in version control for your work. And you can
publish your emacs variant with full history simply putting a mirror on
a web server and pushing your local changes to it.

Once the bidi support is mature enough to be merged on the official
Emacs sources, bzr will help a lot because others will have the
opportunity to browse your branch and thus know what you changed and why
you changed it. They will be able to get a copy of your branch, test it
and suggest patches. And finally, you will push your changes to the
master Emacs branch with just a command, instead of splitting a large
patch in small pieces and committing them one at a time.

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> From:  Óscar_Fuentes Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 21 Nov 2009 23:51:41 +0100
> 
> First, you are not using a version control system for your changes: it
> would be quite scary to me making large changes to a complex code base
> without the ability to undo the changes or inspect how and when they
> were introduced.

I do have history, just not a public one.  And undoing changes to
debug problems is not my style.  If worse comes to worst, I always
have the current v23.x codebase to compare with.

> Second, publishing your work requires making a tarball
> with the modified sources (or the diff against certain tag of Emacs
> CVS).

Since I merge with mainline every few days, I always have a diff
against the current CVS, give or take a few days.  And if I need a
diff against the current CVS, I just need to "cvs up" again.

> Using bzr will bring in version control for your work. And you can
> publish your emacs variant with full history simply putting a mirror on
> a web server and pushing your local changes to it.

If others had offered help working on this, I'd have made a CVS branch
long ago.  But since I'm the only one interested in this for now,
maintaining a branch is just a waste of my time.

Mind you, I'm not arguing that a VCS or bzr are not needed, just that
their impact is minimal in my case.  Nevertheless, I will, of course,
use bzr when we switch to it.  That's why I was asking questions all
this weekend.

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Óscar_Fuentes <ofv@wanadoo.es>

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

Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>,
>     emacs-devel@gnu.org
> Date: Sun, 22 Nov 2009 09:54:47 +0900
> 
> 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.

For someone who comes from CVS (and centralized VCS in general), this
aspect is a no-brainer.

> You are.  *You* apparently don't miss having the VCS record your
> history as you go along, and that's OK.

As I wrote elsewhere, I do have history.

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

I have full records of my design decisions and the history of changes.
So I will be able to answer such questions easily enough.  Not
everything in this world needs to be recorded in a VCS to be readily
available.  Especially if only one individual is working on a project.

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

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

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

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> 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

Re: bzr repository ready?

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> 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.

Is this always true for bzr?  It sounds like it has about 500 different
modes where what exactly is kept around differs...

-Miles

-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

Re: bzr repository ready?

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> 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.
>
> Is this always true for bzr?  It sounds like it has about 500 different
> modes where what exactly is kept around differs...

Bazaar keeps a local copy of the history unless you explicitly ask
otherwise:

bzr checkout URL
bzr branch URL

with both you have local access to the VC history.

bzr checkout --lightweight URL
bzr branch --stacked URL

need to access URL for querying VC data.

-- 
Óscar

Re: bzr repository ready?

[Richard Stallman]

    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'.

They are not equivalent.  The ChangeLog files are included in the
checkout, so you can read them even when you are offline (which is
nearly all the time, for me).  `bzr log' requires contact with the
repository.

The obvious solution, running `bzr log' and saving output to a file
with every update, is not a full solution since it won't give the real
information about branches that were merged.

Is there a way to get all the information about what has been
merged into the current trunk?

Various directories have separate ChangeLog files.  Is that true also
for `bzr log', or is it one log for the whole package?

Another convenience with ChangeLog files is that we split them into
manageable-size parts.  It would be nice to have a script that would
do the same thing to the output of `bzr log', preferring to split
at the points where releases occurred.

Re: bzr repository ready?

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> They are not equivalent.  The ChangeLog files are included in the
> checkout, so you can read them even when you are offline (which is
> nearly all the time, for me).  `bzr log' requires contact with the
> repository.

Yes, but the repository is local too!

There are possible setups in which a repository might be non-local, but
I hope we won't be recommending any of those for Emacs.  In all the bzr
setups I use, logs and other history information are available locally.
This is the normal way to use distributed version control systems, not
just bzr.

By the way, 'bzr log --gnu-changelog' will print the log information in
ChangeLog format.

> Is there a way to get all the information about what has been
> merged into the current trunk?

Yes:

  $ bzr log -n0

Actually, make that:

  ### unplug your network cable...
  $ bzr log -n0
  ### ...watch it work anyway :-)

> Various directories have separate ChangeLog files.  Is that true also
> for `bzr log', or is it one log for the whole package?

One log for the entire "package" ("branch", in bzr terminology).
You can specify subdir arguments, if you only want the logs for
those subdirs.

> Another convenience with ChangeLog files is that we split them into
> manageable-size parts.  It would be nice to have a script that would
> do the same thing to the output of `bzr log', preferring to split
> at the points where releases occurred.

Just use the -r flag to show only logs in a certain date range.
(A script could do that, with the dates set to release dates, of course.)

-Karl

Re: bzr repository ready?

[Richard Stallman]

    > They are not equivalent.  The ChangeLog files are included in the
    > checkout, so you can read them even when you are offline (which is
    > nearly all the time, for me).  `bzr log' requires contact with the
    > repository.

    Yes, but the repository is local too!

Maybe I misunderstood something.  I thought the idea was to make
a local checkout from a remote repository.  Are you saying people
should always copy the whole repository first?

Re: bzr repository ready?

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>     > They are not equivalent.  The ChangeLog files are included in the
>     > checkout, so you can read them even when you are offline (which is
>     > nearly all the time, for me).  `bzr log' requires contact with the
>     > repository.
>
>     Yes, but the repository is local too!
>
> Maybe I misunderstood something.  I thought the idea was to make
> a local checkout from a remote repository.  Are you saying people
> should always copy the whole repository first?

Because I don't know how experienced you are with Bazaar yet, I don't
know if you're using the word "repository" in the CVS sense or in the
Bazaar sense, above.  The two meanings are very different.

What I meant when I said "the repository is local too" is that history
is local, and that therefore you can read it while offline (thus you can
generate ChangeLog information while offline).  By the way, I agree that
we should not switch our ChangeLog practices when we switch version
control systems -- the "change one variable at a time" rule is good.  So
this is just informational; I'm not advocating that we stop keeping
ChangeLog files the moment we switch to Bazaar.

In Bazaar, copying "the whole repository" is easy, and costs about the
same as copying just one branch, but it doesn't mean anything special.
Whether or not you copy the entire repository, you will still have full
historical data for each branch you have locally, by default.  That's
the important thing, whereas copying "the repository" is mainly an
optimization, and does not have the same implications for local access
to historical data that it would in CVS.

Here's an example of creating an empty shared repository locally,
pulling one branch of upstream master Emacs into it, then cheaply
fetching another branch into the repository later:

  $ bzr init-repo emacs-shared-repository
  $ cd emacs-shared-repository
  $ bzr branch URL_TO_UPSTREAM_EMACS_TRUNK
  ### This will take a while, because it's the first fetch
  ### of a great many revisions.
  $ bzr branch URL_TO_UPSTREAM_EMACS_SOME_OTHER_BRANCH
  ### This won't take long at all, because most of the revisions are
  ### already present locally in the shared repository, thanks to the
  ### first branch -- bzr won't pull that data across the wire twice.

Of course, many people just save time by just copying the entire shared
repository at once; that takes about as long as the initial branching of
trunk would have in the example above.  This is what I did to fetch the
most recent test conversion of Emacs, for example:

  $ scp -r kfogel@bzr.savannah.gnu.org:/srv/bzr/emacs emacs-bzr-repository

Now I have _all_ the branches locally, as if I had done 'bzr branch' to
get them.

In my earlier example, the "bzr init-repo ..." step above was optional.
The commands

  $ bzr branch URL_TO_UPSTREAM_EMACS_TRUNK

and

  $ bzr branch URL_TO_UPSTREAM_EMACS_SOME_OTHER_BRANCH

would still work even without a repository, it's just that a) the second
command would pull some data over the wire that the first command had
already pulled, and b) the two branches wouldn't share storage on local
disk, which could add up if you have keep lots of branches locally.

I hope this helps.

-Karl

Re: bzr repository ready?

[Richard Stallman]

    > Maybe I misunderstood something.  I thought the idea was to make
    > a local checkout from a remote repository.  Are you saying people
    > should always copy the whole repository first?

    Because I don't know how experienced you are with Bazaar yet, I don't
    know if you're using the word "repository" in the CVS sense or in the
    Bazaar sense, above.  The two meanings are very different.

    What I meant when I said "the repository is local too" is that history
    is local, and...

We are failing to communicate, because that's not what I was talking
about at all.

    In Bazaar, copying "the whole repository" is easy, and costs about the
    same as copying just one branch,

I see your point, but that difference isn't what I was talking about.

I'm asking about how to use lightweight checkouts.  Someone
recommended them for people not writing lots of changes.

When you make a lightweight checkout, do you have to first make a
local repository and get the branch into it?  Or can you make a
lightweight checkout straight from the remote repository?

I got the impression that the lightweight checkout was recommended
because it avoids the need to make a local repository.  The questions
I've asked are based on that understanding.  The answers I get seem to
suggest the contrary, that the lightweight checkout is made from a
local repository.  But if that's true, I don't see what good the
lightweight checkout does.  Why not edit the local repository's source
files directly?

In other words, after doing 

   bzr branch URL_TO_UPSTREAM_EMACS_TRUNK

why not just go ahead and edit the files in the directory
for that branch?

The text in the wiki seems to say that you pull over a branch with
`bzr branch', and doesn't say anything else is necessary before you
use it.

Is that true?  Once you do that command above, what is the state?
What can you actually DO with the branch at that point?
Do you have to make a checkout from the branch in order to get
source files you can use?

Re: bzr repository ready?

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

[snip]

> I'm asking about how to use lightweight checkouts.  Someone
> recommended them for people not writing lots of changes.

Other than disk space savings, there is no reason for using lightweight
checkouts as a means to write an occassional change. Either you
misunderstood the context of the recommendation (because lightweight
checkouts are widely used on some advanced setups, maybe he was talking
about that) or the recommendation is not good, IMO.

> When you make a lightweight checkout, do you have to first make a
> local repository and get the branch into it?

Not required.

> Or can you make a lightweight checkout straight from the remote
> repository?

Yes.

> I got the impression that the lightweight checkout was recommended
> because it avoids the need to make a local repository.  The questions
> I've asked are based on that understanding.  The answers I get seem to
> suggest the contrary, that the lightweight checkout is made from a
> local repository.

You can make the lightweight from any *branch* (in bazaar, repositories
are just collections of not-necessarily-related branches, used for
optimizing access and storage. A branch is an independent entity: you
don't need a repository for having a branch.)

> But if that's true, I don't see what good the
> lightweight checkout does.  Why not edit the local repository's source
> files directly?
>
> In other words, after doing 
>
>    bzr branch URL_TO_UPSTREAM_EMACS_TRUNK
>
> why not just go ahead and edit the files in the directory
> for that branch?

You can certainly do that. Why most people don't? Because as it is so
easy to clone branches and move revisions from one branch to another
branch in a dVCS, what is recommended is:

1. Create a repository for taking advantage of the space savings and
fast operations it provides.

2. Clone the upstream branch into your repository.

3. Keep that branch as a pristine local mirror of upstream.

4. Clone your upstream local mirror branch for creating another branch
you use for hacking.

From here, there are lots of variations, with a varied degree of
complexity.

> The text in the wiki seems to say that you pull over a branch with
> `bzr branch', and doesn't say anything else is necessary before you
> use it.
>
> Is that true?

Yes.

> Once you do that command above, what is the state?

You have a copy of the branch you cloned. The only thing that
differentiates your new branch from the cloned one is that your new
branch refers to the cloned one as its "parent". For the rest they are
identical.

> What can you actually DO with the branch at that point?

Whatever you please. Really.

> Do you have to make a checkout from the branch in order to get
> source files you can use?

Only if you explicitly requested from the `bzr branch' command that it
shouldn't create the source files:

bzr branch --no-tree URL_TO_UPSTREAM_EMACS_TRUNK
___________^^^^^^^^^

or if you created your repository (in case you are using one, which is
recommended) with

bzr init-repo --no-trees my-repository
______________^^^^^^^^^^

Otherwise, your newly cloned branch will have all the source files ready
to be edited.

Please note that the previous responde to you on this subthread was from
Karl Fogel. I have a different opinion about how those who have no
previous experience with a dVCS should transition to Bazaar. I think it
is unnecessarily confusing for them to go straight for the full
distributed setup. An intermediate step, where you familiarize yourself
with bazaar's interface but use a workflow that is reminiscent of CVS
would simplify the transition. My recommendation is:

bzr init-repo my-repository
cd my-repository
bzr checkout URL_TO_UPSTREAM_EMACS_TRUNK emacs

Now you have the files ready to work. Why I used `bzr checkout' instead
of `bzr branch'? Because the `checkout' creates a "heavyweight
checkout", aka "bound branch", which means that your commits go directly
to upstream, as CVS does, instead of being stored on the branch waiting
for your explicit orders for sending them upstream.

Your daily work would consist on:

<hack, hack, hack>
bzr update
bzr commit
<repeat cycle>

The only additional commands you need to know for now:

bzr status  # says what you edited, what's in conflict state, etc.
bzr resolve [file ...] # For telling bazaar that you solved a conflict.
bzr diff [file ...]
bzr log [file ...]
bzr annotate [file ...]

All those commands are accesible through VC/VC-Dired and work off-line,
except 'update' and 'commit'.

Once you are confident with this and you feel at home with bazaar
interface (a few hours is usually enough), you can migrate to a workflow
that is fully distributed and that allows you having your own branch in
your machine, for committing off-line to that branch and sending the
changes upstream in batches when you are connected.

The key here is that the basic setup I described can be effortless
morphed into whatever workflow you choose to use in the future
(converting a bound branch into an unbound branch or vice-versa requires
just one command) without having to repeat long and painful operations
like re-downloading all the history from upstream, etc.

-- 
Óscar

Re: bzr repository ready?

[Richard Stallman]

    bzr init-repo my-repository
    cd my-repository
    bzr checkout URL_TO_UPSTREAM_EMACS_TRUNK emacs

    Now you have the files ready to work. Why I used `bzr checkout' instead
    of `bzr branch'? Because the `checkout' creates a "heavyweight
    checkout", aka "bound branch", which means that your commits go directly
    to upstream, as CVS does,

That seems like a simple approach.  Thanks.

David De La Harpe Golden wrote:

    That is a reason to make a lightweight checkout from a remote repository 
    alright -  People not writing lots of changes might use such a 
    lightweight checkout from a remote repository as it avoids grabbing the 
    whole branch with full historical data (a couple of hundred megs for 
    emacs, and also doing it with bzr-over-http is slower  that one would 
    expect even given that size for whatever reason)

That makes sense now too.

I think it would be good to document both in the wiki.

Re: bzr repository ready?

[Stephen J. Turnbull]

Richard Stallman writes:

 > I think it would be good to document both in the wiki.

I think that's a mistake.  The approach currently documented in the
wiki is *reasonably* simple, especially for the beta tester or
occasional contributor of code.  Rather than trying to tune their
workflow early, it allows them to grow into more direct or frequent
participation without massive reconfiguration of their environment or
work habits.

Re: bzr repository ready?

[Richard Stallman]

      The approach currently documented in the
    wiki is *reasonably* simple, especially for the beta tester or
    occasional contributor of code.

I find it rather complex, so I will use one of these two simpler
suggestions.  I think we should inform people about these options.

Re: bzr repository ready?

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>       The approach currently documented in the
>     wiki is *reasonably* simple, especially for the beta tester or
>     occasional contributor of code.
>
> I find it rather complex, so I will use one of these two simpler
> suggestions.  I think we should inform people about these options.

Much of the confusion comes from the abundance of workflows bzr
allows. I'm starting to think that pointing out the existence of
alternative workflows only added confusion to the discussion (and I'm
guilty of that). Maybe the right approach was to describe a "blessed"
workflow on the wiki and behave as if the other approaches didn't
exist. This, certainly, would be positive from the pedagogical POV.

If there is real interest on using one of those introductory workflows
I'll write the documentation, unless someone thinks that having two
widely different documents for helping CVS users on the transition will
only create more confussion.

BTW, I pretend to explain the "bound branch" approach, always
emphasizing that is a middle point between CVS and Bazaar and that the
user should eventually transition to a fully dVCS practice unless some
circumstances are met (the user is always connected and writes simple
changes).

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 27 Nov 2009 17:30:59 +0100
> Cc: Richard Stallman <rms@gnu.org>
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > I find it rather complex, so I will use one of these two simpler
> > suggestions.  I think we should inform people about these options.
> 
> Much of the confusion comes from the abundance of workflows bzr
> allows.

Note that Richard didn't say it was confusing.  He said it was
complex.

> I'm starting to think that pointing out the existence of
> alternative workflows only added confusion to the discussion

Personally, I don't think having several workflows adds to confusion.
If they are clearly explained, and if the pros and cons of each one
are described, I can easily make up my mind, and I don't think I'm
special in this regard.

> Maybe the right approach was to describe a "blessed"
> workflow on the wiki and behave as if the other approaches didn't
> exist.

I personally would regret that.  I think I'm grown-up enough to not
have me spoon-fed.  Give me the information and let me decide myself
what's best for me, even if I make some mistakes on the way.

> If there is real interest on using one of those introductory workflows
> I'll write the documentation

FWIW, I'd welcome more information.  Thanks.

> BTW, I pretend to explain the "bound branch" approach, always
> emphasizing that is a middle point between CVS and Bazaar and that the
> user should eventually transition to a fully dVCS practice

What is ``full dVCS practice''?  Can you describe it (or was it
already described in this thread)?

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

>> Maybe the right approach was to describe a "blessed"
>> workflow on the wiki and behave as if the other approaches didn't
>> exist.
>
> I personally would regret that.  I think I'm grown-up enough to not
> have me spoon-fed.  Give me the information and let me decide myself
> what's best for me, even if I make some mistakes on the way.

One thing is to teach how to keep hacking on emacs when CVS is replaced
with Bazaar. This is essential for the transition to be a success. Other
different thing is to teach the users about the possibilities of Bazaar
in particular and dVCS in general. This can be lengthy and difficult, as
most conceptual shifts are.

IMO there is another problem here: that people is too focused on methods
without mastering the concepts. It's my impression that there are quite
a few folks here that have a wrong understanding about what `branch',
`repository' and `revision' means on the context of a dVCS.

>> BTW, I pretend to explain the "bound branch" approach, always
>> emphasizing that is a middle point between CVS and Bazaar and that the
>> user should eventually transition to a fully dVCS practice
>
> What is ``full dVCS practice''?  Can you describe it (or was it
> already described in this thread)?

dVCS, in essence, consists on the idea that you can pull changes from
any developer that published his branch, and any other user can get
changes from your published branches. Here, "upstream" is just an
agreement among developers. That's the only thing that makes the
branches on the GNU server special. This has profound implications on
all aspects of development.

Time to write the guide.

-- 
Óscar

Re: bzr repository ready?

[Richard Stallman]

    dVCS, in essence, consists on the idea that you can pull changes from
    any developer that published his branch, and any other user can get
    changes from your published branches. Here, "upstream" is just an
    agreement among developers. That's the only thing that makes the
    branches on the GNU server special. This has profound implications on
    all aspects of development.

That may be very interesting for some, but I am going to try not to
have to think about it.

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I personally would regret [a document that advocates a particular
 > workflow to start from].  I think I'm grown-up enough to not have
 > me spoon-fed.  Give me the information and let me decide myself
 > what's best for me, even if I make some mistakes on the way.

But BzrForEmacsDevs is not about what's best for you.  Figuring *that*
out is your privilege, and your problem.  BzrForEmacsDevs is about
designing a recommended starter workflow that the majority of Emacs
hackers can adopt without worrying too much, while avoiding the common
mistakes that make life a lot less pleasant for the other people
accessing the repository.

See http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01021.html
for a leading example of the subtleties.

See http://lkml.indiana.edu/hypermail/linux/kernel/0805.2/0539.html
for some of Linus's wisdom on the social aspects of workflows.  That
really rings true for me, but do you have any idea what he's talking
about?

BTW, Dave Miller got 3rd degree burns from the process of Linus
working that out.  I tried to find Linus's flames to give you an idea
of how badly you can piss someone off with poor *social* workflow that
works well for you individually, but no luck.  Maybe somebody has an
URL, it was classic.

 > What is ``full dVCS practice''?  Can you describe it (or was it
 > already described in this thread)?

Heh.  Ask any three developers, you'll get four opinions. :-)

Re: bzr repository ready?

[Lennart Borgman]

On Fri, Nov 27, 2009 at 8:06 PM, Stephen J. Turnbull
<turnbull@sk.tsukuba.ac.jp> wrote:
>
> See http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01021.html
> for a leading example of the subtleties.
>
> See http://lkml.indiana.edu/hypermail/linux/kernel/0805.2/0539.html
> for some of Linus's wisdom on the social aspects of workflows.  That
> really rings true for me, but do you have any idea what he's talking
> about?


Hum. That seems pretty important even though I am pretty sure I do not
understand all the details.

But why are not normal human beeings protected from the evil of
rebase? Why do they have to know about it?

Re: bzr repository ready?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Nov 27, 2009 at 08:22:31PM +0100, Lennart Borgman wrote:

[...]

> Hum. That seems pretty important even though I am pretty sure I do not
> understand all the details.

The principle is quite easy (although details can get messy, as always):
if you have other people depending on your (published) repository, you
better always "move forward" and don't mess with the past (and rebasing
is a mild way of messing with the past). Otherwise "your" past and "your
client's past" won't agree, and that isn't funny.

> But why are not normal human beeings protected from the evil of
> rebase? Why do they have to know about it?

Because when you are developing a local patch derived from some
upstream, rebase is too convenient to ignore it. It lets you "see" your
changes always relative to the "current upstream version" ("as if" you
started developing from there -- and that's the "history changing" bit).

To sum it up -- you may practice revisionism whenever nobody's looking.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLEMcTBcgs9XrR2kYRAnjjAJ40E+aDcLAO99oc5E9P7m2L+9n+HACfbFrH
De3zaiZBC4HnjZRbR70mZRg=
=OVZ4
-----END PGP SIGNATURE-----

Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>,
>     rms@gnu.org,
>     emacs-devel@gnu.org
> Date: Sat, 28 Nov 2009 04:06:40 +0900
> 
> Eli Zaretskii writes:
> 
>  > I personally would regret [a document that advocates a particular
>  > workflow to start from].  I think I'm grown-up enough to not have
>  > me spoon-fed.  Give me the information and let me decide myself
>  > what's best for me, even if I make some mistakes on the way.
> 
> But BzrForEmacsDevs is not about what's best for you.  Figuring *that*
> out is your privilege, and your problem.

You seem to interpret the ``I personally'' thing too literally.  I
wrote that in the personal style, but it should have been clear that I
thought others will feel that way as well: that patronizing us is not
the way to go.  Evidently, it wasn't clear enough, sorry.

> BzrForEmacsDevs is about designing a recommended starter workflow
> that the majority of Emacs hackers can adopt without worrying too
> much, while avoiding the common mistakes that make life a lot less
> pleasant for the other people accessing the repository.

It remains to be proven whether a workflow exists that would be good
for ``the majority of Emacs hackers''.  The wiki page already talks
about several kinds of hackers, and suggest different workflows for
each one of them.

More importantly, what little I've read about dVCS practices suggests
that the best workflow depends heavily on a combination of factors,
such as the number and typical activity levels of core developers, the
amount of overlap in the areas where they and their downstream hackers
develop, the explicit division of maintainership between the core
developers, etc.  I think all these factors change from project to
project, so when a large project such as Emacs switches to a dVCS, it
will take time for us to figure out all these factors and find the
right set of workflows.

So I wouldn't worry too much if several workflows were described on
the wiki, and not a single one, since trying to have a single one
might simply yield a wrong one.

If we worry about a starter workflow, then that can be gleaned from
the Bazaar's getting started tutorial.  It's pretty clear, and
therefore it's easy to get started.

The question that bothers me is what's next.  We didn't decide to
switch to Bazaar just to do the same as we did with CVS.  Therefore,
the issue of the workflows for the Emacs project as a whole and for
the individual developers _should_be_ an important one, not something
swept under the rug because it's deemed ``confusing''.  Nothing is
confusing if it's clearly explained, especially with the audience we
have here: experienced code developers who know one or two things
about data structures and algorithms, so describing some of the inner
workings of Bazaar that underlie some of the recommendations for and
against workflows should not be hard.

Yes, it would make the wiki page substantially longer, but we could
organize it in a way that people who are impatient to get to the
bottom line will have it.

> See http://lkml.indiana.edu/hypermail/linux/kernel/0805.2/0539.html
> for some of Linus's wisdom on the social aspects of workflows.  That
> really rings true for me, but do you have any idea what he's talking
> about?

I think I do, although I don't necessarily see how that's related to
the present discussion.  Perhaps you assume that I want the best
workflow for me at the expense of others.  If so, that's false, and if
what I wrote could somehow be interpreted to that effect, I'm sorry.

What I really meant was that describing several possible workflows
with their pros and cons would enable a discussion among developers
that would yield the set of recommended workflows (I don't believe
there's only one) that would serve well both the individual developers
and their peers, and the project as a whole.

>  > What is ``full dVCS practice''?  Can you describe it (or was it
>  > already described in this thread)?
> 
> Heh.  Ask any three developers, you'll get four opinions. :-)

What's yours, if I may ask?

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > You seem to interpret the ``I personally'' thing too literally.  I
 > wrote that in the personal style, but it should have been clear that I
 > thought others will feel that way as well: that patronizing us is not
 > the way to go.  Evidently, it wasn't clear enough, sorry.

I'm not patronizing anybody.  I'm trying to avoid sinking too much
more of my time into helping Emacs developers learn how to use Bazaar,
while still helping to produce a document that's useful to a lot of
them, and will advance a *few* (not all) basic "best practice" uses of
dVCS.

At present we have a document that I'm happy with and happy to support
by further editing and answering questions.  Put more workflows into
it, and I'll be happy to apply my efforts elsewhere, because I expect
that to result in many more FAQs and I'm not willing to deal with that.

Re: bzr repository ready?

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>     3. Keep that branch as a pristine local mirror of upstream.
>
>     4. Clone your upstream local mirror branch for creating another branch
>     you use for hacking.
>
> If you do that, would you edit directly in this second branch?

Yes.

The goal here is having two local branches: a pristine mirror of
upstream and a sandbox for hacking.

This approach has quite a few more subtleties than the "heavy checkout"
approach I recommend as the start point for CVS users, where commits are
sent to upstream immediately.

-- 
Óscar

Re: bzr repository ready?

[David De La Harpe Golden]

 > We are failing to communicate

I know rather less than Karl about bzr, but I'm one of the ones who 
would be using lightweight checkouts from a local repository,  so I'll 
have a shot:

> I'm asking about how to use lightweight checkouts.  Someone
> recommended them for people not writing lots of changes.
> 
> When you make a lightweight checkout, do you have to first make a
> local repository and get the branch into it? 

Have to? No.
Can you do that if you want to? Yes.
Why would you want to? See *** below.

> Or can you make a lightweight checkout straight from 
 > the remote repository?

Yes.  Though that's then similar to using a non-distributed VCS - a 
better one than CVS, but still, with usual non-distributed VCS 
disadvantages associated with needing to be able to talk to the remote 
"repository" (there's a terminological issue here as bzr is "branch 
centric").

> I got the impression that the lightweight checkout was recommended
> because it avoids the need to make a local repository.  

That is a reason to make a lightweight checkout from a remote repository 
alright -  People not writing lots of changes might use such a 
lightweight checkout from a remote repository as it avoids grabbing the 
whole branch with full historical data (a couple of hundred megs for 
emacs, and also doing it with bzr-over-http is slower  that one would 
expect even given that size for whatever reason)

> In other words, after doing 
> 
>    bzr branch URL_TO_UPSTREAM_EMACS_TRUNK
> 
> why not just go ahead and edit the files in the directory
> for that branch?
>

*** The issue of lightweight checkouts from a _local_ repository arose 
in the case of emulating the git sense of branches (which are not 
materialized as subdirectories in the filesystem).

To pretend bzr is git in this respect (there are other respects in which 
they differ), you can make a local repository (multiple bzr branches 
using the same storage) configured not to populate the branch 
directories with actual working copies of files ("--no-trees") and 
branch the branches you want into it.

Then you do a lightweight checkout of a branch to single working 
directory, then you switch that single working directory between 
lightweight checkouts of your different branches with the "bzr switch" 
command.

This means you have lots less branch directories populated with files, 
assuming you have multiple branches.

A cited disadvantage of "branches are subdirectories" was the need to 
separately "make bootstrap" each branch separately.  If you're switching 
a single working directory between checkouts of branches, you can "get 
away with" not bootstrapping so much, something like switching cvs 
branches with (IIRC) "cvs update -r".

 > Do you have to make a checkout from the branch in order to get
 > source files you can use?

Only if you've made a branch with no working copies of source files with 
the --no-trees option because you're emulating git style as above.

Re: bzr repository ready?

[Stefan Monnier]

> In other words, after doing 

>    bzr branch URL_TO_UPSTREAM_EMACS_TRUNK

> why not just go ahead and edit the files in the directory
> for that branch?

You can definitely do that.  You can then commit those changes locally
with "bzr commit", you can fetch updates from the upstream trunk with
"bzr merge", you can also install those changes into the upstream trunk
with "bzr push".  But the main problem with it in my experience is that
whenever you want to see the local changes that aren't installed yet,
you end up having to do

  bzr diff -r branch:URL_TO_UPSTREAM_EMACS_TRUNK

(which can be shortened to "bzr diff -r submit:") which will need to
contact the remote repository and hence won't work when you're not
connected; furthermore it will show the diff between your branch and the
remote trunk, which will include both your local changes and the changes
you haven't fetched from the remote trunk.  OTOH with a local mirror of
the remote trunk, you can do "bzr diff -r branch:../mirror" (which can
also be shortened to "bzr diff -r submit:") and it will work purely
locally and (assuming you've done a merge since you last updated that
mirror) will only show your local changes.

Note that this mirror can be cheap (like 40KB or so of disk space) since
it doesn't need to contain the actual files (unless you want them to be
there) and your local branch already contains all the needed history
info anyway.


        Stefan

Re: bzr repository ready?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[snip]

> But the main problem with it in my experience is that
> whenever you want to see the local changes that aren't installed yet,
> you end up having to do
>
>   bzr diff -r branch:URL_TO_UPSTREAM_EMACS_TRUNK
>
> (which can be shortened to "bzr diff -r submit:")

bzr missing

is even shorter :-)

[snip]

-- 
Óscar

Re: bzr repository ready?

[Stefan Monnier]

>> But the main problem with it in my experience is that
>> whenever you want to see the local changes that aren't installed yet,
>> you end up having to do
>> 
>> bzr diff -r branch:URL_TO_UPSTREAM_EMACS_TRUNK
>> 
>> (which can be shortened to "bzr diff -r submit:")

> bzr missing
> is even shorter :-)

But with the same problem: if you don't have a local mirror, it'll have
to contact the remote repository.  And it won't show the diffs.


        Stefan

Re: bzr repository ready?

[Stephen J. Turnbull]

Richard Stallman writes:

 > I'm asking about how to use lightweight checkouts.  Someone
 > recommended them for people not writing lots of changes.

They're not in the BzrForEmacsDevs document, and if they appear, I
will *dis*appear and refuse to touch that document thereafter. ;-)

 > I got the impression that the lightweight checkout was recommended
 > because it avoids the need to make a local repository.

That's correct.  There is a better way, however, which is to use
a stacked branch.  Stacked branches

(1) retrieve only enough history to reconstitute the requested version
    of the source tree, and
(2) create new history locally (only locally) when "bzr commit" is invoked.

This has the following purposes:

(1) minimize the time and space cost of the initial branch operation,
(2) allow convenient updating to new upstream versions,
(3) allow people without commit privilege on Savannah to commit
    locally, which
(4) allows them to conveniently maintain both purely local hacks, and
(5) work intended for contribution back to the Emacs project.

It has certain defects:

(1) any operation (such as diff or log) that needs history before the
    initial version must go out to the upstream repo to get it.  Ie,
    it's slow and requires a network connection.

This mode of operation is recommended for beta testers, since they are
likely to start by just updating once in a while, but it imposes
minimum cost if they alter the sources: just commit the change
(locally).  It is *severely* deprecated for core developers.

 > The questions I've asked are based on that understanding.  The
 > answers I get seem to suggest the contrary,

These are experienced users explaining how they would use lightweight
checkouts to their own advantage.  Lightweight checkouts are neither
needed nor recommended for novice bzr users.  (Most of the people
describing how they would use checkouts have said the same thing.)

 > In other words, after doing 
 > 
 >    bzr branch URL_TO_UPSTREAM_EMACS_TRUNK
 > 
 > why not just go ahead and edit the files in the directory
 > for that branch?

There is no reason not to do that, except if you have commit
privileges in the upstream repository.  If you are going to push
directly to the upstream repository, then the roundabout method:

    cd WORKSPACE
    emacs
    bzr commit
    cd MIRROR
    bzr merge WORKSPACE
    bzr push

produces a much nicer "bzr log" output.  That is, the default view in
the upstream branch (and its mirrors) shows only the merge commits.
Each merge log describes the whole task (which might be something as
big as the emacs-unicode development and merge) in *one* log.  You can
also request a detailed output with "bzr log -n0", which lists the
entire history of a branch leading up the the merge.

This may not sound like much to you, but bzr fans consider this a
really important feature.

 > Is that true?  Once you do that command above, what is the state?
 > What can you actually DO with the branch at that point?

After "bzr branch URL_TO_UPSTREAM_EMACS_TRUNK emacs-work" *outside* of
a shared repo, you have in the emacs-work directory

(1) a full source tree as you would get with a CVS checkout, plus
(2) a .bzr directory containing branch configuration metadata (eg,
    project-wide bzr defaults and the source URL), plus
(3) a .bzr/repository directory containing the entire history of the
    upstream branch, including the full history of any branches merged
    into the upstream branch up to the point of the merge.

You may now unplug your computer from the Internet, and go to work,
performing all the operations that one can do with a single Bazaar
branch: commit, diff, log, branch, checkout, status (and some others).
Since you can commit, of course you can edit the files and manage
those changes with bzr.

You cannot push, pull, or update from the parent, of course (you just
pulled the plug!)

If you do "bzr branch URL_TO_UPSTREAM_EMACS_TRUNK emacs-work" *inside*
of shared repository *configured as recommended in the wiki*, you have

(1) a .bzr directory containing branch configuration metadata (eg,
    project-wide bzr defaults and the source URL), plus
(2) a ../.bzr/repository directory containing the entire history of the
    upstream branch, including the full history of any branches merged
    into the upstream branch up to the point of the merge.

Note the ".." in (2).  (In fact it could be more than one level of
parent, but that's not something that novice users need to do.)

To summarize:

 > Do you have to make a checkout from the branch in order to get
 > source files you can use?

If you do "bzr branch" outside of a shared repository, no.  You're
ready to go, but you should not push directly to the upstream branch.

If you do it inside of a shared repository, you need to do something
to reconstitute the source tree.  I recommend the procedure described
in the wiki, *not* a checkout, however.  In fact, I do not know how
the proponents of checkouts propose to preserve "nice" history with
the workflows they describe.

It's probably possible, but I don't know a straightforward recipe
that's less complex than the wiki recommendation.  If somebody does,
they should feel free to edit the wiki.

Re: bzr repository ready?

[Richard Stallman]

    They're not in the BzrForEmacsDevs document, and if they appear, I
    will *dis*appear and refuse to touch that document thereafter. ;-)

I am sure your help would be missed, but that is not the right basis
to decide the question.

Re: bzr repository ready?

[Stephen J. Turnbull]

Richard Stallman writes:
 >     They're not in the BzrForEmacsDevs document, and if they appear, I
 >     will *dis*appear and refuse to touch that document thereafter. ;-)
 > 
 > I am sure your help would be missed, but that is not the right basis
 > to decide the question.

Whether I help or not is not the right basis.  The strength with which
one of the few who are willing to pretend to any expertise at all
holds an opinion is, however, useful information to the nonexpert.

Re: bzr repository ready?

[Richard Stallman]

    That's correct.  There is a better way, however, which is to use
    a stacked branch.  Stacked branches

I don't think I have seen the term "stacked branch" before.  Is it a
different term for something that has been discussed recently,
or is it something substantively different?

Re: bzr repository ready?

[Stephen J. Turnbull]

Richard Stallman writes:

 >     That's correct.  There is a better way, however, which is to use
 >     a stacked branch.  Stacked branches
 > 
 > I don't think I have seen the term "stacked branch" before.  Is it a
 > different term for something that has been discussed recently,
 > or is it something substantively different?

IIRC, it's a different concept; stacked branches are relatively new.
They were developed for use on project hosts like Launchpad[1], where they
can save a huge amount of space for projects with many branches.
There are two dimensions to be considered here.

Terminological note: in this post, by "checkout" I mean a "lightweight
checkout directly from the upstream master branch".  A "committer" is
a "maintainer or other person allowed to send changes directly to the
upstream master branch".

The first is "does plain 'bzr commit' commit to a local repository, to
the parent (typically remote) repository, or to both?"  A normal
branch commits to the local repository, a checkout to the remote
repository, and a bound branch to both.  This means that a normal
branch diverges from its parent branch immediately, a checkout cannot
diverge, and a bound branch does not diverge unless the user takes
some exceptional action.  A *stacked branch*, like a (normal) branch,
commits to the local repository.

The second is "how much of the version history (file content) is
maintained locally?"  In a branch, full history of all versions that
are ancestor to any version in the branch is kept locally.  This is
also true of a bound branch.  In a checkout, no history at all is kept
locally.  A *stacked branch* is different from either: its history is
distributed between the local repository and the remote.  History
*before* the branch point is kept in the remote repository, while
*new* history is kept locally.  ("New history" definitely includes
merges from 3rd party branches and new commits, and IIRC also includes
updates from the parent branch).

A summary table is attached at the bottom.

Aside from small additional space savings, for committers the
advantage of a checkout over a stacked branch is that all of her
commits are immediately reflected in the upstream master, saving her
the effort of typing "bzr push".  The disadvantage is that all of her
commits are immediately reflected in the upstream master, costing her
the effort of managing the changes by hand while improving and testing
them, because she can't commit until the patch is "good".

For non-committer hackers, the checkout is an all-around loss compared
to the stacked branch.  They cannot commit at all in the checkout.  In
return for this handicap, they can save a small amount of space.

For non-hackers (ie, beta testers) the checkout saves a small amount
of space at no cost since there's no need to commit.  I still advocate
use of stacked branches here, in hope that someday soon they will
experience a sudden urge to commit.

\ local history
   \  content      Full        Truncated        None
commit \
target  +-------------------+---------------+------------+
        |        (normal)   |   stacked     |            |
Local   |         branch    |    branch     |            |
        +-------------------+---------------+------------+
Remote  |                   |               |  checkout  |
        +-------------------+---------------+------------+
Both    |         bound     |               |            |
        |         branch    |               |            |
        +-------------------+---------------+------------+

Footnotes: 
[1]  I write "Launchpad" because this refers specifically to
Launchpad's feature of giving each developer a personal shared
repository for her "sandbox" branches.  If the "sandbox" branches are
instead kept in the main shared repository, then there will be no
additional space savings from making them stacked branches.  I'm not
familiar with Savannah's architecture.

Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 27 Nov 2009 18:14:13 +0900
> Cc: kfogel@red-bean.com, ofv@wanadoo.es, emacs-devel@gnu.org
> 
> Richard Stallman writes:
> 
>  >     That's correct.  There is a better way, however, which is to use
>  >     a stacked branch.  Stacked branches
>  > 
>  > I don't think I have seen the term "stacked branch" before.  Is it a
>  > different term for something that has been discussed recently,
>  > or is it something substantively different?
> 
> IIRC, it's a different concept; stacked branches are relatively new.
> They were developed for use on project hosts like Launchpad[1], where they
> can save a huge amount of space for projects with many branches.
> There are two dimensions to be considered here.

Thanks for the explanations.  So what would be the workflow of an
Emacs hacker who also has write access to the master repository, with
stacked branches?  (If this is described in some existing document, a
pointer there is all I need, thanks.)

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Thanks for the explanations.  So what would be the workflow of an
 > Emacs hacker who also has write access to the master repository, with
 > stacked branches?

There is no such workflow.  For developers, stacked branches are a
space optimization at the expense of great inconvenience in all
accesses to history, including bzr log and bzr diff.  When using one
of the more specialized workflows that Óscar and Jason have described,
you'd use checkouts or bound branches, not stacked branches.

Stacked branches were recommended for *beta testers* because it makes
the transition from tester to occasional hacker much easier than with
a checkout, but they have much less immediate need for convenient
access to history than the kind of hacker who becomes a committer.

Re: bzr repository ready?

[Richard Stallman]

    Aside from small additional space savings, for committers the
    advantage of a checkout over a stacked branch is that all of her
    commits are immediately reflected in the upstream master,

Another advantage is conceptual simplicity.

      The disadvantage is that all of her
    commits are immediately reflected in the upstream master, costing her
    the effort of managing the changes by hand while improving and testing
    them, because she can't commit until the patch is "good".

In what sense is this a disadvantage?  I don't see it.  I don't see
the benefit in doing commits to a local branch before the change is
finished.  If some people find that useful, I have nothing against
their doing it, but I can't see why I should go to that trouble.

Re: bzr repository ready?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>       The disadvantage is that all of her
>     commits are immediately reflected in the upstream master [...]

> In what sense is this a disadvantage?  I don't see it.  I don't see
> the benefit in doing commits to a local branch before the change is
> finished [...]

I'm not a heavy DCVS user myself, but I must say this ability of
micro-branching and of keeping record of micro-steps is one of the
features I've come to appreciate most in the "new" workflow. It's
addictive :-)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLEMglBcgs9XrR2kYRAnnqAJ9sIdUUy605hL2d4bRWeWIiQUNp0wCdG64Z
76w+c+/rqOmlc7aBuBDFDXE=
=pBh9
-----END PGP SIGNATURE-----

Re: bzr repository ready?

[Stephen J. Turnbull]

Richard Stallman writes:

 > If some people find [the recommended workflow] useful, I have
 > nothing against their doing it, but I can't see why I should go to
 > that trouble.

Well, then, don't.

I'm not interested in what any individual decides to do.  I'm trying
to propose a plausible, straightforward transition strategy adapted to
the circumstances of Emacs and the capabilities of Bazaar, for those
who don't know what to do, and are willing to make a small effort in
the transition, but would rather not spend many hours reading the
Bazaar docs.  I think the proposal in BzrForEmacsDevs satisfies those
criteria.

Re: bzr repository ready?

[Richard Stallman]

    I'm not interested in what any individual decides to do.  I'm trying
    to propose a plausible, straightforward transition strategy adapted to
    the circumstances of Emacs and the capabilities of Bazaar, for those
    who don't know what to do, and are willing to make a small effort in
    the transition, but would rather not spend many hours reading the
    Bazaar docs.  I think the proposal in BzrForEmacsDevs satisfies those
    criteria.

I agree with those goals.  I think this proposal is not right for
them.  It proposes a rather complex way of using bzr, which may be
good for people writing medium to large changes, but is unnecessarily
complex for most of the people who are looking for such a
recommendation.

Re: bzr repository ready?

[Stephen J. Turnbull]

Richard Stallman writes:

 > I agree with [your] goals.  I think this proposal is not right for
 > them.  It proposes a rather complex way of using bzr, which may be
 > good for people writing medium to large changes, but is unnecessarily
 > complex for most of the people who are looking for such a
 > recommendation.

OK.  I am not going to invest effort in diversifying the document,
however.  Perhaps Óscar will merge his document into the main one.

Re: bzr repository ready?

[Óscar Fuentes]

[This is a resend with a corrected header. Sorry if it appears as a
duplicated]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Richard Stallman writes:
>
>  > I agree with [your] goals.  I think this proposal is not right for
>  > them.  It proposes a rather complex way of using bzr, which may be
>  > good for people writing medium to large changes, but is unnecessarily
>  > complex for most of the people who are looking for such a
>  > recommendation.
>
> OK.  I am not going to invest effort in diversifying the document,
> however.  Perhaps Óscar will merge his document into the main one.

Everytime I open a technical document and see that the vertical
scrollbar thumb fills a good chunk of its allowed space, I feel
relieved. So I prefer to keep my document on its own page, where it
looks shorter. Perhaps putting a text at the end of your document like
"if you think that this is insanely complicated there is a simpler, less
powerful approach described on BzrQuickStartForEmacsDevs"

BTW, you don't advertise any Emacs package for working with the
distributed workflows. The only one I know for Bazaar is DVC [1], which
looks quite useful although with some rough edge. Maybe it is a good
idea mentioning it.

1: http://www.xsteve.at/prg/index.html

-- 
Óscar

Re: bzr repository ready?

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > So I prefer to keep my document on its own page, where it
 > looks shorter. Perhaps putting a text at the end of your document like
 > "if you think that this is insanely complicated there is a simpler, less
 > powerful approach described on BzrQuickStartForEmacsDevs"

OK.  I've compromised and added the URL to the references.

 > BTW, you don't advertise any Emacs package for working with the
 > distributed workflows.

No, and I don't think it's a good idea for the transition period.
Those interfaces are not for novices yet.  Novices should use the
command line or Bazaar Explorer (or Tortoise if they're on Windows, I
guess).  vc will eventually catch up.

Re: bzr repository ready?

[@ 2009-11-29 4:18 UTC (permalink / raw)]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Richard Stallman writes:
>
>  > I agree with [your] goals.  I think this proposal is not right for
>  > them.  It proposes a rather complex way of using bzr, which may be
>  > good for people writing medium to large changes, but is unnecessarily
>  > complex for most of the people who are looking for such a
>  > recommendation.
>
> OK.  I am not going to invest effort in diversifying the document,
> however.  Perhaps Óscar will merge his document into the main one.

Everytime I open a technical document and see that the vertical
scrollbar thumb fills a good chunk of its allowed space, I feel
relieved. So I prefer to keep my document on its own page, where it
looks shorter. Perhaps putting a text at the end of your document like
"if you think that this is insanely complicated there is a simpler, less
powerful approach described on BzrQuickStartForEmacsDevs"

BTW, you don't advertise any Emacs package for working with the
distributed workflows. The only one I know for Bazaar is DVC [1], which
looks quite useful although with some rough edge. Maybe it is a good
idea mentioning it.

1: http://www.xsteve.at/prg/index.html

-- 
Óscar

Re: bzr repository ready?

[Richard Stallman]

    Everytime I open a technical document and see that the vertical
    scrollbar thumb fills a good chunk of its allowed space, I feel
    relieved. So I prefer to keep my document on its own page, where it
    looks shorter. Perhaps putting a text at the end of your document like
    "if you think that this is insanely complicated there is a simpler, less
    powerful approach described on BzrQuickStartForEmacsDevs"

The simpler approach should be the first recommendation we mention,
because it will be right for more people, and so that those people
won't get discouraged trying to understand the more complex approach.

Whether we put them in one page or two is just a detail.

Re: bzr repository ready?

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>    Everytime I open a technical document and see that the vertical
>    scrollbar thumb fills a good chunk of its allowed space, I feel
>    relieved. So I prefer to keep my document on its own page, where it
>    looks shorter. Perhaps putting a text at the end of your document like
>    "if you think that this is insanely complicated there is a simpler, less
>    powerful approach described on BzrQuickStartForEmacsDevs"
>
> The simpler approach should be the first recommendation we mention,
> because it will be right for more people, and so that those people
> won't get discouraged trying to understand the more complex approach.

We should point people first to BzrForEmacsDevs (which describes a
natively distributed setup), and just make sure that people know the
other approaches are available if they want that.

Elsewhere, I have seen people new to Bazaar make the mistake of trying
an approach that seemed "simpler" to them (usually similar to what they
were accustomed to from CVS and Subversion), only to pay the price later
when most other Bazaar users couldn't support them or understand the way
they were working -- because what they were doing was so different from
the way one works with Bazaar once one knows Bazaar.

Once you understand Bazaar, BzrForEmacsDevs actually feels *less*
complex (because it uses the default type of branch and a standard
distributed workflow), while BzrQuickStartForEmacsDevs feels more
complex (because it involves a bound branch and a non-distributed
workflow).

Offering options is not itself a problem, as long as we help people
choose among those options.  All our documents should make clear that
the native dVCS approach is the recommended way, and that the
quick-start way should be considered a stopgap.  Then each person will
be informed enough to make the right decision for them.

The way to do that is to point to the full dVCS way by default, while
making sure that the quick-start way is readily available, and that the
relationship between the documents is clear.

-Karl

Re: bzr repository ready?

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> I agree with those goals.  I think this proposal is not right for
> them.  It proposes a rather complex way of using bzr, which may be
> good for people writing medium to large changes, but is unnecessarily
> complex for most of the people who are looking for such a
> recommendation.

I think that once you have actually tried the workflow there (after the
switchover) you will find it is not hard to use.

It is certainly the way I would choose to make changes of any size to
Emacs.

-Karl

Re: bzr repository ready?

[Richard Stallman]

    I think that once you have actually tried the workflow there (after the
    switchover) you will find it is not hard to use.

I don't expect to ever try it.  I am very busy, and I don't think
it will be worth the effort.  I am going to use the simple method.

You're asking people to invest a substantial effort, saying they
will find it worth while.  Those who do a substantial amount of
use of bzr may indeed find it so.  But I probably won't use it
that much, so for me the investment would not be worth while.
I am sure there are many others in the same position.

Re: bzr repository ready?

[Karl Fogel]

On Mon, Nov 30, 2009 at 11:10 PM, Richard Stallman <rms@gnu.org> wrote:
>    I think that once you have actually tried the workflow there (after the
>    switchover) you will find it is not hard to use.
>
> I don't expect to ever try it.  I am very busy, and I don't think
> it will be worth the effort.  I am going to use the simple method.
>
> You're asking people to invest a substantial effort, saying they
> will find it worth while.  Those who do a substantial amount of
> use of bzr may indeed find it so.  But I probably won't use it
> that much, so for me the investment would not be worth while.
> I am sure there are many others in the same position.

It's fine if you use the CVS-like method; you don't ever have to go
beyond that if you don't want to.

The documentation as it stands states clearly why it is better for
most people to learn the dVCS method.  Those people (like you) who
know that they do not want it do not have to learn the dVCS way.

Elsewhere you wrote:

> You are pushing too hard for people to use the more complex dVCS
> workflow.

You are pushing the Bazaar-knowledgeable people on this list to
support a workflow they themselves rarely use, and that they find
counterintuitive.  (And it's not "more complex".  It's different; to
those who are accustomed to it, it's simpler.)

As far as I can tell, all of those working on this migration who
actually have experience migrating other people and projects from
centralized systems to Bazaar agree that strongly encouraging the dVCS
workflow is the best thing to do.  You do not have that experience, so
I'm not sure what your opposite opinion is based on.

It's fine if some people consciously choose to hang back and continue
to use a centralized-style workflow -- no one has a problem with that.
I'll even answer questions about it when I am able to.

But there is no reason for the project as a whole to encourage it.
And since you already know what you are going to do, you are not
really harmed or impeded by documentation that recommends a different
way as the default but also documents the way you want to work.

So I don't understand your objection.  The CVS-like documentation
exists; it is referred to prominently from the top of the dVCS
documentation; and the relationship between the two is perfectly
clear.

If you want those of us writing it to also pretend neutrality between the
two ways ourselves, that's not going to happen.

-Karl

Re: bzr repository ready?

[Richard Stallman]

    You are pushing the Bazaar-knowledgeable people on this list to
    support a workflow they themselves rarely use, and that they find
    counterintuitive.

I am saying our documentation should be present it prominently as a a
legitimate and plausible option.  Since "support" means a lot of other
things too, I think your paraphrase does not represent what I actually
say.

      (And it's not "more complex".  It's different; to

It certainly is more complex.  Compare how long the documentation of
each one is!

    those who are accustomed to it, it's simpler.)

I'm concerned with how much work it is to learn.  You are evidently
talking about something else, something about what it is like to use
once you are accustomed to it.

    As far as I can tell, all of those working on this migration who
    actually have experience migrating other people and projects from
    centralized systems to Bazaar agree that strongly encouraging the dVCS
    workflow is the best thing to do.

"Best" in what sense?  Best for whom?  It is certainly not best for
users like me.  It would require us me to take a lot of time to learn
things that aren't worth while for us.

    But there is no reason for the project as a whole to encourage it.

The point is not to discourage it.  (I've stated the reason before.)
We should not push people into learning the complex method if they are
doing small changes.

    And since you already know what you are going to do,

There are other people in the same situation who have not
read it yet.

      The CVS-like documentation
    exists; it is referred to prominently from the top of the dVCS
    documentation; and the relationship between the two is perfectly
    clear.

I am glad if that is still the case.  Someone was talking about trying
to hide it so as to put pressure on people to use the distributed
method.  I want that not to be done.

Re: bzr repository ready?

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> I am glad if that is still the case.  Someone was talking about trying
> to hide it so as to put pressure on people to use the distributed
> method.  I want that not to be done.

That will not be done.  It will not be hidden (as has been made clear in
this thread already).

-Karl

Re: bzr repository ready?

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>     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'.
>
> They are not equivalent.  The ChangeLog files are included in the
> checkout, so you can read them even when you are offline (which is
> nearly all the time, for me).  `bzr log' requires contact with the
> repository.

Unless you explicitly request it, a bzr branch or checkout carries the
full history of the branch. So `bzr log' does not need contact with the
repository.

A bzr branch in your machine carries all version control data that you
could get from the CVS server for that branch.

> The obvious solution, running `bzr log' and saving output to a file
> with every update, is not a full solution since it won't give the real
> information about branches that were merged.
>
> Is there a way to get all the information about what has been
> merged into the current trunk?

Yes: bzr log -n1

You can even see the history of the branches that were merged into the
branches that were merged into the branches [repeat n times] that finally
were merged into trunk:

bzr log -n0

And everything without net access.

> Various directories have separate ChangeLog files.  Is that true also
> for `bzr log', or is it one log for the whole package?

bzr log elisp

will show the log of the subset of the history that touches files on the
elisp directory, for instance. This works for all files and directories.

> Another convenience with ChangeLog files is that we split them into
> manageable-size parts.  It would be nice to have a script that would
> do the same thing to the output of `bzr log', preferring to split
> at the points where releases occurred.

You can ask to see the log between two points. A point can be a revision
number or a tag.

bzr log -r tag:sometag..

shows the log from the tag `sometag' to the last revision.

-- 
Óscar

Re: bzr repository ready?

[Richard Stallman]

    Unless you explicitly request it, a bzr branch or checkout carries the
    full history of the branch. So `bzr log' does not need contact with the
    repository.

Does that apply to "lightweight checkouts" which is what someone said
we should use?  Or are you talking about "normal" checkouts, which reportedly
are almost obsolete and going to be discontinued?

Re: bzr repository ready?

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>     Unless you explicitly request it, a bzr branch or checkout carries the
>     full history of the branch. So `bzr log' does not need contact with the
>     repository.
>
> Does that apply to "lightweight checkouts" which is what someone said
> we should use?  Or are you talking about "normal" checkouts, which reportedly
> are almost obsolete and going to be discontinued?

There are terminology changes going on, and I'm not fully up-to-date
with those.  But the *semantics* are not changing: the normal way to use
Bazaar is to fetch full historical data with each branch, so you have
everything locally, and this is also what we are recommending for Emacs
development.  Don't let the terminology kerfuffle fool you.

-Karl

Re: bzr repository ready?

[Richard Stallman]

    There are terminology changes going on, and I'm not fully up-to-date
    with those.  But the *semantics* are not changing: the normal way to use
    Bazaar is to fetch full historical data with each branch, so you have
    everything locally, and this is also what we are recommending for Emacs
    development.

I am not sure how to reconcile that statement with what people said
about lightweight checkouts -- that they are comparable to CVS checkouts
in what they contain.

Is the idea of lightweight checkouts that you first make a local repository
and then make a lightweight checkout from that?

Re: bzr repository ready?

[Jason Earl]

Richard Stallman <rms@gnu.org> writes:

>     There are terminology changes going on, and I'm not fully
>     up-to-date with those.  But the *semantics* are not changing: the
>     normal way to use Bazaar is to fetch full historical data with
>     each branch, so you have everything locally, and this is also what
>     we are recommending for Emacs development.
>
> I am not sure how to reconcile that statement with what people said
> about lightweight checkouts -- that they are comparable to CVS
> checkouts in what they contain.

Yes, a lightweight checkout is comparable to a CVS checkout in that it
relies on the branch it is pointing to for history.  If you created a
lightweight checkout from a remote branch you would be coming as close
to recreating CVS as is possible with a more modern version control
system.  Bzr would still give you atomic commits, and the ability to
move files around without losing history (to name a few advantages), but
you would have to be connected to the network for most commands to work.

> Is the idea of lightweight checkouts that you first make a local
> repository and then make a lightweight checkout from that?

Yes, that's it precisely.  Lightweight checkouts basically allow you to
create a working tree from a branch that you have in the repository.  If
you only plan on having one branch on your local machine then a
lightweight checkout is *not* what you want.  However, if you are
working on several different branches at the same time and you don't
want to have several different copies of the Emacs source code lying
around (with the attendant requirement to run make bootstrap on each of
these source trees), then a lightweight checkout is the solution to your
problem.

In that case you create a local repository to hold your branches and you
connect a lightweight checkout to the local branch you want to hack on
using "bzr switch".  If later you need to hack on a different branch you
commit your changes to your local branch and bzr switch to the other
branch and hack there.  Your source tree will be changed to match the
contents of the branch that you switch too, and all of the unversioned
files (like the stuff make bootstrap generates) will be there so that
make will only build what needs to be built.

If you have read:

http://www.emacswiki.org/emacs/BzrForEmacsDevs

You'll notice that it doesn't cover lightweight checkouts at all as
these checkouts are a more advanced topic.  Lightweight checkouts are
handy, but they are not necessary.  I personally think that many Emacs
hackers are likely to end up using them in the long run, but bzr allows
for a great deal of flexibility when it comes to designing your own
workflow.

Jason

Re: bzr repository ready?

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>     Unless you explicitly request it, a bzr branch or checkout carries the
>     full history of the branch. So `bzr log' does not need contact with the
>     repository.
>
> Does that apply to "lightweight checkouts" which is what someone said
> we should use?

No, lightweight checkouts carry no history. They are just the source
files and a pointer to the upstream branch, so they need to contact the
original repository from they were created for all
operations. Lightweight checkouts have its uses on certain advanced bzr
workflows or in the case that you can't afford 300 MB of hard disk
storage for storing the version control history.

> Or are you talking about "normal" checkouts,

Yes.

> which reportedly are almost obsolete and going to be discontinued?

What is going to be obsoleted and discontinued is just the
terminology. "normal" checkouts, aka heavy checkouts, are now termed by
the bzr developers as "bound branches".

-- 
Óscar

Re: bzr repository ready?

[Glenn Morris]

Richard Stallman wrote:

>     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'.
>
> They are not equivalent. 

This issue has already been addressed, let's not get sidetracked.

http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00334.html

    From:   Stefan Monnier
    Subject: Re: Switching to bzr: what Emacs developers should know?
    Date:   Sat, 08 Aug 2009 21:23:21 -0400

    Check the mailing list, we've been very clear about this: we're only
    going to change the underlying tool for now, so ChangeLog aren't
    affected.

Re: bzr repository ready?

[Jason Earl]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

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

That's not entirely true.  I keep a "workspace" checkout in my
repository and then "bzr switch" between the branches that I am working
on.  It probably doesn't work exactly like git, but it certainly allows
you to switch between branches without doing a make bootstrap.  Commits
go to the right place, the branch nick gets set correctly, switching is
fast, and make does the right thing.

Jason

Re: bzr repository ready?

[Eli Zaretskii]

> From: Jason Earl <jearl@notengoamigos.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  =?utf-8?Q?=C3=93scar?= Fuentes
>  <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Sat, 21 Nov 2009 22:13:57 -0700
> 
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> 
> > 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.
> 
> That's not entirely true.  I keep a "workspace" checkout in my
> repository and then "bzr switch" between the branches that I am working
> on.  It probably doesn't work exactly like git, but it certainly allows
> you to switch between branches without doing a make bootstrap.  Commits
> go to the right place, the branch nick gets set correctly, switching is
> fast, and make does the right thing.

But that means you already bootstrapped each branch at least once,
right?  Or did I misunderstand the functionality of "bzr switch"
and/or how you use it?

Re: bzr repository ready?

[Jason Earl]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jason Earl <jearl@notengoamigos.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  =?utf-8?Q?=C3=93scar?= Fuentes
>>  <ofv@wanadoo.es>,  emacs-devel@gnu.org
>> Date: Sat, 21 Nov 2009 22:13:57 -0700
>> 
>> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>> 
>> > 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.
>> 
>> That's not entirely true.  I keep a "workspace" checkout in my
>> repository and then "bzr switch" between the branches that I am
>> working on.  It probably doesn't work exactly like git, but it
>> certainly allows you to switch between branches without doing a make
>> bootstrap.  Commits go to the right place, the branch nick gets set
>> correctly, switching is fast, and make does the right thing.
>
> But that means you already bootstrapped each branch at least once,
> right?  Or did I misunderstand the functionality of "bzr switch"
> and/or how you use it?

No, you can simply bootstrap the "workspace" checkout.  In fact, I
usually create the rest of the branches either with the --no-tree option
or in a repository initialized with --no-trees.  So the workspace
checkout is the only directory that even has any sources.

So for example, you simply create a repository like so:

bzr init-repo --no-trees emacs

Then cd into the repository and create a mirror branch of mainline like
so:

cd emacs
cvs branch http://bzr.savannah.gnu.org/r/emacs/trunk/ trunk

This will create a directory that is a branch, but the branch will not
have any files in it.

Now let's imagine that you want to do some actual hacking in a branch
that you call dev.  You would create the branch like so:

bzr branch trunk dev

Finally you create a workspace directory.  This is the only directory
that actually has any sources in it.

bzr co --lightweight dev workspace

From within the workspace directory you can change branches with the
switch command.  For example in the root of the workspace directory you
would type:

bzr switch ../trunk

to switch to the trunk.

This setup allows you to switch between as many branches as you might
care to make without having to do a make bootstrap in each, and indeed
without having to waste space on duplicate (or nearly duplicate) copies
of the source.

Of course, if you prefer, you can also use bzr almost precisely as you
use CVS today.

Jason

Re: bzr repository ready?

[Eli Zaretskii]

> From: Jason Earl <jearl@notengoamigos.org>
> Cc: stephen@xemacs.org,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Sun, 22 Nov 2009 13:32:50 -0700
> 
> So for example, you simply create a repository like so:
> 
> bzr init-repo --no-trees emacs
> 
> Then cd into the repository and create a mirror branch of mainline like
> so:
> 
> cd emacs
> cvs branch http://bzr.savannah.gnu.org/r/emacs/trunk/ trunk
> 
> This will create a directory that is a branch, but the branch will not
> have any files in it.

How do I do this if my repository is local, downloaded with the scp
command discussed elsewhere in this thread?

> Now let's imagine that you want to do some actual hacking in a branch
> that you call dev.  You would create the branch like so:
> 
> bzr branch trunk dev
> 
> Finally you create a workspace directory.  This is the only directory
> that actually has any sources in it.
> 
> bzr co --lightweight dev workspace
> 
> From within the workspace directory you can change branches with the
> switch command.  For example in the root of the workspace directory you
> would type:
> 
> bzr switch ../trunk
> 
> to switch to the trunk.
> 
> This setup allows you to switch between as many branches as you might
> care to make without having to do a make bootstrap in each, and indeed
> without having to waste space on duplicate (or nearly duplicate) copies
> of the source.

I miss the main issue here: what happens with files you actually
change on some branch when you switch to another branch?  Does bzr
magically revert them to the version of that other branch, behind my
back?  For example, let's say I modified foo.el on some branch, and
then re-built Emacs.  I now have foo.elc and an Emacs binary that have
it preloaded (let's say it's one of those loaded at dump time).  Then
I switch to another branch -- what versions of foo.el, foo.elc, and
the Emacs binary will I see now?

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> So for example, you simply create a repository like so:
>> 
>> bzr init-repo --no-trees emacs
>> 
>> Then cd into the repository and create a mirror branch of mainline like
>> so:
>> 
>> cd emacs
>> cvs branch http://bzr.savannah.gnu.org/r/emacs/trunk/ trunk
>> 
>> This will create a directory that is a branch, but the branch will not
>> have any files in it.
>
> How do I do this if my repository is local, downloaded with the scp
> command discussed elsewhere in this thread?

In that case you already have the branches, but the files are inside the
metadata. So cd to a branch (`trunk', for instance) and do

bzr checkout

`checkout' is an overloaded command in bzr. Here it means "populate this
branch with the corresponding working tree (i.e. the files you
edit)". But please read my previous response to Stephan where I say some
things about trees/no-tress and `cp' issue.

>> Now let's imagine that you want to do some actual hacking in a branch
>> that you call dev.  You would create the branch like so:
>> 
>> bzr branch trunk dev
>> 
>> Finally you create a workspace directory.  This is the only directory
>> that actually has any sources in it.
>> 
>> bzr co --lightweight dev workspace
>> 
>> From within the workspace directory you can change branches with the
>> switch command.  For example in the root of the workspace directory you
>> would type:
>> 
>> bzr switch ../trunk
>> 
>> to switch to the trunk.
>> 
>> This setup allows you to switch between as many branches as you might
>> care to make without having to do a make bootstrap in each, and indeed
>> without having to waste space on duplicate (or nearly duplicate) copies
>> of the source.
>
> I miss the main issue here: what happens with files you actually
> change on some branch when you switch to another branch?  Does bzr
> magically revert them to the version of that other branch, behind my
> back?

Not behind your back, because that was precisely what you asked for with
`bzr switch'.

> For example, let's say I modified foo.el on some branch, and
> then re-built Emacs.  I now have foo.elc and an Emacs binary that have
> it preloaded (let's say it's one of those loaded at dump time).  Then
> I switch to another branch -- what versions of foo.el, foo.elc, and
> the Emacs binary will I see now?

foo.el will be the one on the branch you switched to. foo.elc and the
emacs binary will be the same as before. bzr knows nothing about
non-versioned files, and even less about products such as .elc files and
executables, so you need to do a `make'. If the switch changed some file
that is a dependency of the emacs executable and the makefiles work as
they should, it will be rebuilt, which is the case here because file.el
was modified.

-- 
Óscar

Re: bzr repository ready?

[Stephen J. Turnbull]

Jason Earl writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > 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.
 > 
 > That's not entirely true.  I keep a "workspace" checkout in my
 > repository and then "bzr switch" between the branches that I am working
 > on.

Sure, what I wrote isn't 100% accurate.  But it's close enough, and
reasonably intelligible to novices (at least I tried to make it so).

So please, as Eli implicitly requested, let's talk one workflow at a
time.  I'm fine if you want to change to a different workflow which is
admittedly better, but what you just wrote is not an explanation of a
different workflow, or even an admission that you *are* talking about
a different workflow.  It's merely a laundry list of new vocabulary
for novices to learn, with no definitions.  And Eli *did* ask about
the workflow I wrote about.  In more detail:

In git the workflow in question is

1.  Observe an issue.  Plan a design and task to deal with it.
2.  "git checkout -b issue-oriented-task"    # create and checkout new branch
3.  Hack away.
4.  "git commit -a -m 'Here is a problem and how I solved it.'"
5.  "make"
6.  Run tests.
7.  If problems, goto 4.
8.  "git checkout master; git merge issue-oriented-task; git push"

These git operations are very fast and transparent; this is a winning
workflow.  In bzr, the same workflow is implemented

1.  Observe an issue.  Plan a design and task to deal with it.
2.  "bzr branch trunk issue-oriented-task"
3.  "cd issue-oriented-task"
4.  Hack away.
5.  "bzr commit -m 'Here is a problem and how I solved it.'"
6.  Prepare to test: "make bootstrap"
7.  Run tests.
8.  If problems, goto 4.
9.  "cd ../trunk; bzr merge issue-oriented-task; bzr commit; bzr push"

This workflow sucks because steps 2 and 6 are slow, but people more
familiar with git than bzr are likely to remember it, adopt it
themselves (and be frustrated and switch back to git), and recommend
it to novices (who will also experience frustration).

Now you're suggesting an alternative which is just about as efficient
as the git workflow.  *But* there's an important difference.  Both
workflows described above depend only on the existence of a mirror
branch; otherwise they are standalone, they work just as well for a
single contribution as for a regular contributor.  The workflow you
are suggesting, though, has some components that look like the above,
and others that involve preexisting context (several branches, for
example) and new commands which are actually old commands with new
names (bzr switch, at least).  Somebody needs to explain all that (and
it's not going to be me, unless Tim O is about to offer me a book
contract ;-).

Re: bzr repository ready?

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Nov 22, 2009 at 06:45:29PM +0900, Stephen J. Turnbull wrote:

[...]

> In git the workflow in question is
> 
> 1.  Observe an issue.  Plan a design and task to deal with it.
> 2.  "git checkout -b issue-oriented-task"    # create and checkout new branch
> 3.  Hack away.
> 4.  "git commit -a -m 'Here is a problem and how I solved it.'"
> 5.  "make"
> 6.  Run tests.
> 7.  If problems, goto 4.
                       ^^^

Nit: should be 3. Seems your linker is off-by-one ;-D

> 8.  "git checkout master; git merge issue-oriented-task; git push"


> [...] unless Tim O is about to offer me a book contract ;-).

He should, because you are very good at explaining things.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLCTe8Bcgs9XrR2kYRAkx+AJ9g4QauTBuxBW+yyIfwww4EInpqAACggSmj
db/75gRy06YBhlLHYycZgTY=
=6nFU
-----END PGP SIGNATURE-----

Re: bzr repository ready?

[Jason Earl]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Jason Earl writes:
>  > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > 
>  > > 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.
>  > 
>  > That's not entirely true.  I keep a "workspace" checkout in my
>  > repository and then "bzr switch" between the branches that I am
>  > working on.
>
> Sure, what I wrote isn't 100% accurate.  But it's close enough, and
> reasonably intelligible to novices (at least I tried to make it so).
>
> So please, as Eli implicitly requested, let's talk one workflow at a
> time.  I'm fine if you want to change to a different workflow which is
> admittedly better, but what you just wrote is not an explanation of a
> different workflow, or even an admission that you *are* talking about
> a different workflow.  It's merely a laundry list of new vocabulary
> for novices to learn, with no definitions.  And Eli *did* ask about
> the workflow I wrote about.  In more detail:
>
> In git the workflow in question is
>

> 1.  Observe an issue.  Plan a design and task to deal with it.
> 2.  "git checkout -b issue-oriented-task" # create and checkout new
>     branch.
> 3.  Hack away.
> 4.  "git commit -a -m 'Here is a problem and how I solved it.'"
> 5.  "make"
> 6.  Run tests.
> 7.  If problems, goto 4.
> 8.  "git checkout master; git merge issue-oriented-task; git push"
>
> These git operations are very fast and transparent; this is a winning
> workflow.  In bzr, the same workflow is implemented

On the one hand you chide me for adding a slight change to the bzr
workflow that you were criticizing while, on the other hand, you bring
up an entirely different set of tools.

If the criticism of bzr is that it doesn't have colocated branches
requiring several instances of "make bootstrap" then here is how you
solve it.

If what you want to do is talk about how great git is, then I suppose
that is helpful as well, but it certainly isn't going to help Emacs
developers that are switching to bzr.

The revised example assumes that you have a mirror branch named "trunk"
and a light checkout named "workspace" created in the bzr repository
like this:

bzr co --lightweight trunk workspace

> 1.  Observe an issue.  Plan a design and task to deal with it.
> 2.  "bzr branch trunk issue-oriented-task"
> 3.  "cd issue-oriented-task"

3 (revised). cd workspace ; bzr switch ../issue-oriented-task

> 4.  Hack away.
> 5.  "bzr commit -m 'Here is a problem and how I solved it.'"
> 6.  Prepare to test: "make bootstrap"

6 (revised). "make"

> 7.  Run tests.
> 8.  If problems, goto 4.
> 9.  "cd ../trunk; bzr merge issue-oriented-task; bzr commit; bzr push"

With that one minor change the bzr workflow works just like the git
one.  Of course, it assumes that you have a checkout in your repository
called "workspace" where you do your work, but creating such a checkout
is a single command.

You can even leave off the --lightweight flag and it will work precisely
the same (at least from an end user's point of view).

> This workflow sucks because steps 2 and 6 are slow, but people more
> familiar with git than bzr are likely to remember it, adopt it
> themselves (and be frustrated and switch back to git), and recommend
> it to novices (who will also experience frustration).

If the repository is created with --no-trees, or if the step 2. is
replaced with "bzr branch --no-tree trunk issue-oriented-task" then step
2 is basically instantaneous.  On my underpowered Dell netbook running
Ubuntu GNU/Linux this is how long it takes to create a branch in bzr if
a workspace is not created:

time bzr branch --no-tree trunk/ foo
Branched 98737 revision(s).

real    0m0.771s
user    0m0.680s
sys     0m0.088s

I am sure git does it in half the time, but bzr is fast enough in this
case that I doubt anyone would care.

Since you are reusing the workspace (like git) now step 6 is precisely
the same as the git workflow.

> Now you're suggesting an alternative which is just about as efficient
> as the git workflow.  *But* there's an important difference.  Both
> workflows described above depend only on the existence of a mirror
> branch; otherwise they are standalone, they work just as well for a
> single contribution as for a regular contributor.  The workflow you
> are suggesting, though, has some components that look like the above,
> and others that involve preexisting context (several branches, for
> example) and new commands which are actually old commands with new
> names (bzr switch, at least).  Somebody needs to explain all that (and
> it's not going to be me, unless Tim O is about to offer me a book
> contract ;-).

For one off contributions the bzr workflow probably looks like this.

1. bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/ emacs
2. cd emacs
3. hack
4. bzr commit -m "Hooray I fixed it"
5. Test
6. If problems 3
7. bzr send -o awesome-fix.patch

For CVS refugees that have commit rights and aren't interested in
leveraging bzr as a DVCS they can basically keep precisely the same
workflow that they currently use.

1. bzr co [the magical ssh url that I don't happen to know] emacs
2. cd emacs
3. hack
4. bzr up (no -dP needed)
5. bzr commit

The difference is that bzr will probably be faster for basically every
operation than CVS because it has a local cache.  Emacs' vc-mode stuff
will even do the right thing.  For this group bzr is almost certainly a
more straightforward change than git.  For example, there is no need to
worry about the push, pull, or merge commands.  Nor is there any
requirement to learn about how git juggles branches.  Perhaps best of
all vc-mode will work just like it always has.

Clearly, these are extreme cases, but they are cases that appear to
apply directly to Emacs development.  For those whose needs lie
somewhere in between it is probably a good idea to create a repository
that includes a light checkout that can be switched to various branches
so that you don't have to "make bootstrap" more than necessary.  This
requires a few extra steps (two extra steps, that only need to be done
once, to be precise), but unlike git, bzr doesn't force you to worry
about branches unless you actually want to start dealing with them.

If, like Eli, you aren't convinced that a DVCS is for you, then bzr
won't force you to learn to use one.  On the other hand if you really
like git's colocated branches bzr can be easily set up to approximate
them.

Jason

Re: bzr repository ready?

[Eli Zaretskii]

> From: Jason Earl <jearl@notengoamigos.org>
> Cc: =?utf-8?Q?=C3=93scar?= Fuentes <ofv@wanadoo.es>,  Eli Zaretskii
>  <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 22 Nov 2009 16:43:21 -0700
> 
> If, like Eli, you aren't convinced that a DVCS is for you

Hey, I never said that, nor even though that!  Switching to bzr is a
decision that was made long time ago, and the only thing I'm
interested in now is to learn how to use it efficiently in the
shortest time and with minimum wasted effort.

Re: bzr repository ready?

[Jason Earl]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Jason Earl writes:
>  > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > 
>  > > 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.
>  > 
>  > That's not entirely true.  I keep a "workspace" checkout in my
>  > repository and then "bzr switch" between the branches that I am
>  > working on.
>
> Sure, what I wrote isn't 100% accurate.  But it's close enough, and
> reasonably intelligible to novices (at least I tried to make it so).
>
> So please, as Eli implicitly requested, let's talk one workflow at a
> time.  I'm fine if you want to change to a different workflow which is
> admittedly better, but what you just wrote is not an explanation of a
> different workflow, or even an admission that you *are* talking about
> a different workflow.  It's merely a laundry list of new vocabulary
> for novices to learn, with no definitions.  And Eli *did* ask about
> the workflow I wrote about.  In more detail:
>
> In git the workflow in question is
>

> 1.  Observe an issue.  Plan a design and task to deal with it.
> 2.  "git checkout -b issue-oriented-task" # create and checkout new
>     branch.
> 3.  Hack away.
> 4.  "git commit -a -m 'Here is a problem and how I solved it.'"
> 5.  "make"
> 6.  Run tests.
> 7.  If problems, goto 4.
> 8.  "git checkout master; git merge issue-oriented-task; git push"
>
> These git operations are very fast and transparent; this is a winning
> workflow.  In bzr, the same workflow is implemented

On the one hand you chide me for adding a slight change to the bzr
workflow that you were criticizing while, on the other hand, you bring
up an entirely different set of tools.

If the criticism of bzr is that it doesn't have colocated branches
requiring several instances of "make bootstrap" then here is how you
solve it.

If what you want to do is talk about how great git is, then I suppose
that is helpful as well, but it certainly isn't going to help Emacs
developers that are switching to bzr.

The revised example assumes that you have a mirror branch named "trunk"
and a light checkout named "workspace" created in the bzr repository
like this:

bzr co --lightweight trunk workspace

> 1.  Observe an issue.  Plan a design and task to deal with it.
> 2.  "bzr branch trunk issue-oriented-task"
> 3.  "cd issue-oriented-task"

3 (revised). cd workspace ; bzr switch ../issue-oriented-task

> 4.  Hack away.
> 5.  "bzr commit -m 'Here is a problem and how I solved it.'"
> 6.  Prepare to test: "make bootstrap"

6 (revised). "make"

> 7.  Run tests.
> 8.  If problems, goto 4.
> 9.  "cd ../trunk; bzr merge issue-oriented-task; bzr commit; bzr push"

With that one minor change the bzr workflow works just like the git
one.  Of course, it assumes that you have a checkout in your repository
called "workspace" where you do your work, but creating such a checkout
is a single command.

You can even leave off the --lightweight flag and it will work precisely
the same (at least from an end user's point of view).

> This workflow sucks because steps 2 and 6 are slow, but people more
> familiar with git than bzr are likely to remember it, adopt it
> themselves (and be frustrated and switch back to git), and recommend
> it to novices (who will also experience frustration).

If the repository is created with --no-trees, or if the step 2. is
replaced with "bzr branch --no-tree trunk issue-oriented-task" then step
2 is basically instantaneous.  On my underpowered Dell netbook running
Ubuntu GNU/Linux this is how long it takes to create a branch in bzr if
a workspace is not created:

time bzr branch --no-tree trunk/ foo
Branched 98737 revision(s).

real    0m0.771s
user    0m0.680s
sys     0m0.088s

I am sure git does it in half the time, but bzr is fast enough in this
case that I doubt anyone would care.

Since you are reusing the workspace (like git) now step 6 is precisely
the same as the git workflow.

> Now you're suggesting an alternative which is just about as efficient
> as the git workflow.  *But* there's an important difference.  Both
> workflows described above depend only on the existence of a mirror
> branch; otherwise they are standalone, they work just as well for a
> single contribution as for a regular contributor.  The workflow you
> are suggesting, though, has some components that look like the above,
> and others that involve preexisting context (several branches, for
> example) and new commands which are actually old commands with new
> names (bzr switch, at least).  Somebody needs to explain all that (and
> it's not going to be me, unless Tim O is about to offer me a book
> contract ;-).

For one off contributions the bzr workflow probably looks like this.

1. bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/ emacs
2. cd emacs
3. hack
4. bzr commit -m "Hooray I fixed it"
5. Test
6. If problems 3
7. bzr send -o awesome-fix.patch

For CVS refugees that have commit rights and aren't interested in
leveraging bzr as a DVCS they can basically keep precisely the same
workflow that they currently use.

1. bzr co [the magical ssh url that I don't happen to know] emacs
2. cd emacs
3. hack
4. bzr up (no -dP needed)
5. bzr commit

The difference is that bzr will probably be faster for basically every
operation than CVS because it has a local cache.  Emacs' vc-mode stuff
will even do the right thing.  For this group bzr is almost certainly a
more straightforward change than git.  For example, there is no need to
worry about the push, pull, or merge commands.  Nor is there any
requirement to learn about how git juggles branches.  Perhaps best of
all vc-mode will work just like it always has.

Clearly, these are extreme cases, but they are cases that appear to
apply directly to Emacs development.  For those whose needs lie
somewhere in between it is probably a good idea to create a repository
that includes a light checkout that can be switched to various branches
so that you don't have to "make bootstrap" more than necessary.  This
requires a few extra steps (two extra steps, that only need to be done
once, to be precise), but unlike git, bzr doesn't force you to worry
about branches unless you actually want to start dealing with them.

If, like Eli, you aren't convinced that a DVCS is for you, then bzr
won't force you to learn to use one.  On the other hand if you really
like git's colocated branches bzr can be easily set up to approximate
them.

Jason

Re: bzr repository ready?

[Stephen J. Turnbull]

Jason Earl writes:

 > On the one hand you chide me for adding a slight change to the bzr

I did not.  I criticized you for adding a pile of vocabulary without
explaining it.

 > If the criticism of bzr is that it doesn't have colocated branches
 > requiring several instances of "make bootstrap" then here is how you
 > solve it.

No.  It's a *warning* that dVCS fans, of whom there are several on
this list, often *will* recommend a naive and inefficient "bzr branch"
as the first step in any workflow.  Óscar Fuentes in a related
subthread admits to doing exactly in a different context (cloning a
remote branch vs remote file copying a tarball), and the wiki still
does so.  That is a bad idea for many tasks, which really should use
alternative workflows.  But they *are* alternative workflows, and are
*not* explained on the Emacs wiki.

The rest of your post is very much what I was looking for.  Well done!

One quibble:

 > On the other hand if you really like git's colocated branches bzr
 > can be easily set up to approximate them.

No, it is *not* easy, unless you use a definition of "approximate"
that will be unacceptable to many git fans.  Agreed, the "lightweight
checkout plus bzr switch" workflow has similar efficiency properties
for most tasks, but there's a lot more to the git model than just fast
"git checkout".

Re: bzr repository ready?

[Jason Earl]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Jason Earl writes:
>
>  > On the one hand you chide me for adding a slight change to the bzr
>
> I did not.  I criticized you for adding a pile of vocabulary without
> explaining it.

I have re-read my responses and you are absolutely correct.  Heck, even
if you weren't correct I should have been more civil.  Please forgive
me.

>  > If the criticism of bzr is that it doesn't have colocated branches
>  > requiring several instances of "make bootstrap" then here is how
>  > you solve it.
>
> No.  It's a *warning* that dVCS fans, of whom there are several on
> this list, often *will* recommend a naive and inefficient "bzr branch"
> as the first step in any workflow.  Óscar Fuentes in a related
> subthread admits to doing exactly in a different context (cloning a
> remote branch vs remote file copying a tarball), and the wiki still
> does so.  That is a bad idea for many tasks, which really should use
> alternative workflows.  But they *are* alternative workflows, and are
> *not* explained on the Emacs wiki.

That makes sense.  I have certainly experimented with enough
pathologically bad bzr workflows.  Using the right workflow can make a
big difference, and I would be the first to admit that the "proper" bzr
workflow might not be readily apparent.

> The rest of your post is very much what I was looking for.  Well done!

You are welcome.

> One quibble:

Fah, like I said, I re-read my posts.  You are being generous here.

>  > On the other hand if you really like git's colocated branches bzr
>  > can be easily set up to approximate them.
>
> No, it is *not* easy, unless you use a definition of "approximate"
> that will be unacceptable to many git fans.  Agreed, the "lightweight
> checkout plus bzr switch" workflow has similar efficiency properties
> for most tasks, but there's a lot more to the git model than just fast
> "git checkout".

I think it goes without saying that git fans are unlikely to ever think
too highly of bzr.  Once you have learned how to use git effectively
everything else is a step down.  The bzr or hg devs probably have some
arguments to the contrary, but generally speaking git's weakness is that
it is hard to learn to use.

Personally, I think that git's insistence on colocated branches is a
large part of what makes it hard to learn.  Learning to juggle branches
in git certainly confused the heck out of me.  It is somewhat ironic to
me that I have come full-circle and I now tend to do my work in a
lightweight checkout that I point at the right branch with bzr switch.
In at least one project that workspace isn't even inside the repository.
My workspace is at ~/project-name and my repository full of branches is
tucked away at ~/repos/project-name/branches .

A fancy aliasing plugin for bzr that automatically mapped commands like
"bzr switch foo" to "bzr switch $HIDDENREPO/project-name/foo" would get
me even closer to approximating git's colocated branches.  The truly
scary thing (to me anyway) is that I now can see *why* git has the UI
that it does.

Now that I have learned to use bzr, I could probably wrap my head around
git :).

Jason

Re: bzr repository ready?

[David De La Harpe Golden]

Jason Earl wrote:


> My workspace is at ~/project-name and my repository full of branches is
> tucked away at ~/repos/project-name/branches .
> 


As a git user, I've been trying to set up for emacs bzr tracking, and 
perked up a bit at your posts suggesting bzr could be more git like. 
With searching, I then found  http://bazaar-vcs.org/GitStyleBranches

So I've been trying to work out one thing in particular - is there a bzr 
analogue of the distinction between master and remotes/origin/master ? 
I'm a bit confused by bzr "trunk" seemingly serving some double duty as 
a remote tracking and local branch in setup guides so far, so my 
(possibly quite contrary) stab at setting up went like the below.

I'm unclear on how to / if I should tell bzr that remotes-origin-trunk 
is a remote tracking  branch (bzr bind?)

I /think/ bzr push --remember allows me to setup to push from my trunk 
to elsewhere while still merging from remotes-origin-trunk to my trunk 
(which I'd do after a bzr pull to update remotes-origin-trunk from 
origin trunk, by analogy to a git fetch) ?

cd /usr/local/src

bzr whoami "Joe Murphy <jomu@example.com>"
bzr init-repo --no-trees emacs-bzr-repo
bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk \
  emacs-bzr-repo/remotes-origin-trunk
bzr branch emacs-bzr-repo/remotes-origin-trunk emacs-bzr-repo/trunk
mv emacs emacs-cvs-old
bzr checkout --lightweight ../emacs-bzr-repo/trunk emacs

cd emacs
./configure
make -j8 bootstrap
make install

bzr branch . ../emacs-bzr-repo/dev
bzr switch ../emacs-bzr-repo/dev

Re: bzr repository ready?

[Karl Fogel]

David De La Harpe Golden <david@harpegolden.net> writes:
> As a git user, I've been trying to set up for emacs bzr tracking, and
> perked up a bit at your posts suggesting bzr could be more git
> like. With searching, I then found
> http://bazaar-vcs.org/GitStyleBranches
>
> So I've been trying to work out one thing in particular - is there a
> bzr analogue of the distinction between master and
> remotes/origin/master ? I'm a bit confused by bzr "trunk" seemingly
> serving some double duty as a remote tracking and local branch in
> setup guides so far, so my (possibly quite contrary) stab at setting
> up went like the below.
>
> I'm unclear on how to / if I should tell bzr that remotes-origin-trunk
> is a remote tracking  branch (bzr bind?)
>
> I /think/ bzr push --remember allows me to setup to push from my trunk
> to elsewhere while still merging from remotes-origin-trunk to my trunk
> (which I'd do after a bzr pull to update remotes-origin-trunk from
> origin trunk, by analogy to a git fetch) ?

I may misunderstand the question, but I think this will help you:

  * The names of branches are whatever their owners want to call them,
    and it doesn't matter if two branches have the same name.

  * 'bzr push --remember DEST means the next time you can just do
    'bzr push' and it will push to that same DEST.

  * Suppose you have local branch LB, related to (originally branched
    from) upstream branch UB.  After you send changes from LB to UB, you
    can pull from UB to LB and, of course, it won't send those changes,
    because LB already has them.  It will send changes LB doesn't have.

  * You could instead send those changes from LB to SOME_OTHER_BRANCH,
    and thence to YET_ANOTHER_BRANCH, and thence to UB.  If you did
    that, when you pull from UB to LB, there will still be no problem,
    and the changes won't get sent, because LB already has them.

  * There are ways that history can get sort of twisted up; however, the
    methods we are recommending for Emacs development avoid that.  See
    the oft-referred-to http://www.emacswiki.org/emacs/BzrForEmacsDevs.

The question of who is "remote" and who is not depends on point of
view.  I don't _think_ bzr has the concept of a remote tracking branch,
at least not one that is used very often; but someone who knows better
might follow up to correct that (I hope they will).

(Posting from my Canonical address, to see if it works reliably now.  If
you don't get this, please let me know :-) .)

-Karl

Re: bzr repository ready?

[David De La Harpe Golden]

Karl Fogel wrote:

> I may misunderstand the question, but I think this will help you:
>

Thanks, it's also possible I'm just too confused/tired/dumb to ask
a clear question.

>   * 'bzr push --remember DEST means the next time you can just do
>     'bzr push' and it will push to that same DEST.
> 

But not also decide to pull from DEST, right? i.e. it
push and pull's --remembers are independent?

>   * Suppose you have local branch LB, related to (originally branched
>     from) upstream branch UB.    After you send changes from LB to UB, you
>     can pull from UB to LB and, of course, it won't send those changes,
>     because LB already has them.  It will send changes LB doesn't have.
> 

That's the thing - Are you skipping a step here? At least, you've
got no _manifest_ local mirror of UB. I suppose the data's basically 
there underneath.  Why aren't I implicitly or explicitly making a local 
remote-tracking branch RB mirroring UB, then local branch LB ?  Or 
alternatively, if LB is the local mirror of UB, why am I sending changes 
from it - Why am I changing it in the first place? See below.

> The question of who is "remote" and who is not depends on point of
> view. 

Well, exactly, hence remote-tracking branches.

 > See
 > the oft-referred-to http://www.emacswiki.org/emacs/BzrForEmacsDevs.

*** Well, see, that strongly suggests to me the local branch "trunk" 
_is_ the bzr analog of remote-tracking branch:

"""Now, create a branch called trunk that will just be a mirror of the 
mainline. You’ll never do any development in this branch; its job is 
just to reflect the upstream master:"""

"""The --no-tree option prevents an automatic checkout of the source 
tree. This has two functions. It saves some space. More important, it 
reduces the temptation to edit sources in this branch to almost nothing 
— so that you don’t accidentally commit any local changes on it."""

*** Except for the bit where someone ...commits local changes on it... 
Wait, what?

Fortunately, I'm not an upstream committer, I'll presumably be sending 
or asking upstream committers to pick stuff from my public tree, but 
still, I'm clearly missing something.

"""Alternatively, if you are a committer, you may want to push to the 
upstream master.

       cd $DEVHOME/emacs/trunk/
       bzr pull
       bzr merge ../quickfixes

and then commit

       bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."
which automatically pushes all your new commits to the upstream master, 
because the mirror is set up as bound branch.
"""

*** why is this happening on branch trunk and not a branch
my-trunk branched from trunk?  Can it, say, happen on such a branch 
my-trunk (not quickfixes, given dire warnings about history messing up 
if you do that) without ill effect, just to stop my brain hurting? Or
is that just as apparently bad as pushing from quickfixes would be?

Re: bzr repository ready?

[Stephen J. Turnbull]

David De La Harpe Golden writes:

 > That's the thing - Are you skipping a step here? At least, you've
 > got no _manifest_ local mirror of UB.

You don't have one in git, either, only a ref labelled with the
remotes/ prefix. 

 > Why aren't I implicitly or explicitly making a local
 > remote-tracking branch RB mirroring UB, then local branch LB ?

In the recommended workflow in BzrForEmacsDevs, "trunk" is precisely a
manually-maintained remote tracking branch.  bzr will not do this for
you, you have to do it yourself.

 > *** Except for the bit where someone ...commits local changes on it... 
 > Wait, what?

You don't commit any local changes, because you didn't make any in
that branch.  You *merge* local changes to it from your working
branch, and these are *automatically* passed on to the upstream master
when you commit.

 > Fortunately, I'm not an upstream committer, I'll presumably be sending 
 > or asking upstream committers to pick stuff from my public tree, but 
 > still, I'm clearly missing something.

No, actually you're not missing anything.  At least, you've already
noticed that bzr is not git, and that's all that's going on here.

 > and then commit
 > 
 >        bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."
 >
 > which automatically pushes all your new commits to the upstream master, 
 > because the mirror is set up as bound branch.
 > """
 > 
 > *** why is this happening on branch trunk

Because branch trunk is bound to the upstream master, it is not
possible to commit unless the implied push is a fast-forward.  This is
exactly what you want; if the commit fails, you simply do "bzr pull
--overwrite" (or "bzr revert; bzr pull", I forget which I wrote in
BzrForEmacsDevs), and then do the "merge-to-SOMETASK, maybe fix merge
conflicts, merge-back-to-trunk" dance again.

 > and not a branch my-trunk branched from trunk?

Because it's pointless to do that.  The race condition in using
my-trunk (not bound to upstream master) means that you can succeed in
committing the merge, but fail the push.  So you rm -rf my-trunk[1],
and start over, with "bzr branch trunk my-trunk".  Yuck.  If my-trunk
*is* bound to upstream master, things work nicely (losing the race is
fail-safe), but branch "trunk" is redundant.


Footnotes: 
[1]  In principle.  It's actually feasible to rollback history in this
case, but there's no way I'm going to describe that in a document for
newbies because the conditions for safety require a lot of
understanding of bzr theory of ops.

Re: bzr repository ready?

[David De La Harpe Golden]

Thanks for the reply!

> In the recommended workflow in BzrForEmacsDevs, "trunk" is precisely a
> manually-maintained remote tracking branch. 

Right so.

> You don't commit any local changes, because you didn't make any in
> that branch.  You *merge* local changes to it from your working
> branch,

well, to the working tree of branch trunk, not to the branch as such?

> and these are *automatically* passed on to the upstream master
> when you commit.

So hybrid of D and non-D VCS.  I suppose that's why "bound branch" was 
"checkout", it was by an analogy to non-D VCS where a cvs commit
goes off to the remote server.  What happens when you commit "on" a
bound branch without network connectivity?  I guess it just fails,
since you're not really committing to the bound branch but rather
to the associated remote upstream branch?

> Because it's pointless to do that.  The race condition in using
> my-trunk (not bound to upstream master) means that you can succeed in
> committing the merge, but fail the push. 

Well, I suppose in the git world one just tends to avoid many committers 
in the first place (since given DVCS  there's no actual need for much 
shared access beyond perhaps some redundancy), and the occasional 
conflict isn't the end of the world.  Maybe it's easier to rewrite 
history in git though, I know nothing of bzr (though I did just find bzr 
rebase)

Re: bzr repository ready?

[Stephen J. Turnbull]

David De La Harpe Golden writes:

 > > You don't commit any local changes, because you didn't make any in
 > > that branch.  You *merge* local changes to it from your working
 > > branch,
 > 
 > well, to the working tree of branch trunk, not to the branch as such?

Uhm ... you're comparing with git merge, which commits-unless-conflict?  
That's right, a "bzr merge" is entirely VC-data-to-working tree (you
can do it from a branch or a specially-formatted merge directive file)
operation, and doesn't automatically commit.

My point was that the commit in the suggested workflow is based on VCS
data, and therefore reversible and recoverable.  It's not based on
user changes, which would be irrecoverable if you did something like
"bzr pull --overwrite".

The whole suggested workflow is designed with two principles in mind:

1.  A user shall not be asked to choose between committing the content
    of his workspace and getting an update from upstream.
2.  The default view presented by "bzr log" shall be the list of the
    user's commits in his workspace, and the list of contributions
    (each of which may contain a long sequence of commits) in the
    upstream master and its mirrors.

I don't really care, but no. 2 is a feature that people who like
Bazaar love until the fur comes off.

Caveat: in the above, I'm speaking for myself, not for Karl.

 > > and these are *automatically* passed on to the upstream master
 > > when you commit.
 > 
 > So hybrid of D and non-D VCS.  I suppose that's why "bound branch" was 
 > "checkout", it was by an analogy to non-D VCS where a cvs commit
 > goes off to the remote server.

Yes.  And that analogy is even closer with "checkout --lightweight",
which is why the terminology (and the default) is moving in that
direction.

 > What happens when you commit "on" a bound branch without network
 > connectivity?  I guess it just fails, since you're not really
 > committing to the bound branch but rather to the associated remote
 > upstream branch?

Yes.  If you know you're disconnected, you can do "bzr commit
--local".  As Stefan mentioned in passing, there are some issues with
this.  I don't know whether it's in the implementation of Bazaar or in
the implementation of Stefan ;-), but if it's the latter, I'm sure
you're aware that that implementation is quite advanced and robust, so
this feature is hard to use. :-)

 > > Because it's pointless to do that.  The race condition in using
 > > my-trunk (not bound to upstream master) means that you can succeed in
 > > committing the merge, but fail the push. 
 > 
 > Well, I suppose in the git world one just tends to avoid many
 > committers in the first place (since given DVCS there's no actual
 > need for much shared access beyond perhaps some redundancy),

That's false.  Decentralized project workflows like Emacs's do need
it.  The more centralized single-maintainer and gatewayed project
architectures (a la the well-known punk code artists "Linus and His
Lieutenants") don't, of course, but distributed VCS supports a wide
variety of workflows.

Be that as it may, the current proposal AIUI is to emulate the current
CVS-based *project-level* workflow as closely as possible.
Individuals with experience with dVCS are welcome to vary their own
workflows as they please, but as you will observe in this thread rms
and Eli Z are (to a greater or lesser extent personally) concerned
with workflow disruption, and Stefan has explicitly indicated that at
first minimizing disruption is a goal (sine qua non?)

 > and the occasional conflict isn't the end of the world.  Maybe it's
 > easier to rewrite history in git though, I know nothing of bzr
 > (though I did just find bzr rebase)

Much easier!  Don't rewrite history in Bazaar.  It's very limited,
painful, dangerous[1], and worst of all :-) you will be treated as a
pariah by many in the Bazaar community.

Footnotes: 
[1]  It's non-trivial to recover an obsoleted head.  No reflogs, no
documentation of the commands needed to find heads.

Re: bzr repository ready?

[Stephen J. Turnbull]

Karl Fogel writes:

 > It does.  See
 > 
 >   http://www.emacswiki.org/emacs/BzrForEmacsDevs#RegularContributors
 > 
 > (I'm sure it could be improved, of course.)

How about moving it to doc.bazaar-vcs.org where it can benefit the
whole world, leaving a pointer on EmacsWiki?  Or vice-versa, although
I tend to the former because it will be easier to link to related
Bazaar resources on doc.bazar-vcs.

Re: bzr repository ready?

[Lennart Borgman]

On Sat, Nov 21, 2009 at 5:41 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Karl Fogel writes:
>
>  > It does.  See
>  >
>  >   http://www.emacswiki.org/emacs/BzrForEmacsDevs#RegularContributors
>  >
>  > (I'm sure it could be improved, of course.)
>
> How about moving it to doc.bazaar-vcs.org where it can benefit the
> whole world, leaving a pointer on EmacsWiki?  Or vice-versa, although
> I tend to the former because it will be easier to link to related
> Bazaar resources on doc.bazar-vcs.


There is no easy way to comment on doc.bazar-vcs. Surprisingly you can
not comment on the same page.

Perhaps it is therefore better to leave it on EmacsWiki until relavant
questions and critique have been entered and move it later?

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Fri, 20 Nov 2009 17:49:58 -0500
> Cc: emacs-devel@gnu.org
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> > Bazaar supports quite a few models and can be confusing for those who
> > only know the centralized paradigm. IMHO the documentation should
> > recommend a model for beginners and give very detailed instructions for
> > it (maybe already does, I didn't read it).
> 
> It does.  See
> 
>   http://www.emacswiki.org/emacs/BzrForEmacsDevs#RegularContributors

What I'm missing from that description is how do I get my branch
available to others.  I'm guessing that there's a possibility to have
the branch in the master repository, and there's another possibility
to have my local branch published from my machine directly.  But the
wiki currently describes neither of these two (apologies if it does,
and I missed that).

Re: bzr repository ready?

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>>   http://www.emacswiki.org/emacs/BzrForEmacsDevs#RegularContributors
>
> What I'm missing from that description is how do I get my branch
> available to others.  I'm guessing that there's a possibility to have
> the branch in the master repository, and there's another possibility
> to have my local branch published from my machine directly.  But the
> wiki currently describes neither of these two (apologies if it does,
> and I missed that).

Hunh.  AFAIK this information was there a long time ago, but in any case
Stephen Turnbull has been editing the page recently and this information
is definitely on the page now (btw, thanks Stephen).

Look for the sentence that, as of right now, reads "Once your bugfix is
ready, you'll want to send it upstream."

-Karl

Re: bzr repository ready?

[Eli Zaretskii]

> X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,
> 	UNPARSEABLE_RELAY autolearn=unavailable version=3.1.0
> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 20 Nov 2009 21:39:11 +0100
> 
> On bzr parlance there are no lightweight branches.

But the EmacsWiki page does use the "lightweight branch" terminology.
Should it be corrected?

> A non lightweight checkout supports committing changes without sending
> them to the parent branch, using a command line option.

When and why would this be useful?

> A lightweight checkout does not support this because it lacks the
> local VC data.

Would a lightweight checkout from the master repository be a good idea
for people who do not intend to send patches, just build the current
development version?

> Actually, a non lightweight checkout is what Bazaar calls a bound
> branch. You can unbind a non-ligthweigth checkout anytimme for
> converting it to a regular branch and you can bind a branch to some
> other branch to convert it to a checkout of that branch.

So checkouts and branches are mostly the same?

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > But the EmacsWiki page does use the "lightweight branch" terminology.
 > Should it be corrected?

Yes.

 > > A non lightweight checkout supports committing changes without sending
 > > them to the parent branch, using a command line option.
 > 
 > When and why would this be useful?

It's useful for splitting your history into bite-size, coherent pieces
that you aren't ready to push to the mainline.  For example, you might
add an argument to foofunc in foo.el, and fix all the calls in core
Lisp.  Now you commit.  Next you go through all the packages, and fix
them up too, with a separate commit to each one, because you're not as
sure you understand the code in each one.  This allows you to add a
comment explaining your uncertainty to the commit log, or have the
package's principal maintainer veto that commit only while everything
else goes through.

Then you cd to your local copy of the mainline branch, merge that
branch into it, and push to the public repo.  By default bzr log will
show only that the whole branch got merged, but someone who is curious
can see the detailed history.

 > > A lightweight checkout does not support this because it lacks the
 > > local VC data.
 > 
 > Would a lightweight checkout from the master repository be a good idea
 > for people who do not intend to send patches, just build the current
 > development version?

Yes.  I take back what I wrote in my previous response; this is indeed
an *excellent* third reason for lightweight checkouts, probably much
more important than "casual contribution".

 > > Actually, a non lightweight checkout is what Bazaar calls a bound
 > > branch. You can unbind a non-ligthweigth checkout anytimme for
 > > converting it to a regular branch and you can bind a branch to some
 > > other branch to convert it to a checkout of that branch.
 > 
 > So checkouts and branches are mostly the same?

No.  In principle, a checkout is not a branch at all.  It contains the
working tree, but no history, and by default only enough metadata to
tell bzr which repository to get history and other metadata from.
Since the parent repository may be on another host, "log", "diff", and
"commit" become expensive operations, and pull and push are no-ops.

On the other hand, a branch *is* a line of historical development.  It
is the history.  The working tree is optional (and some workflows use
shared repositories that contain only treeless branches).

A "bound branch" used to be called a "heavyweight checkout", the idea
being that most of the time you operate as a checkout but when
necessary (you're on the train, your ISP is taking a siesta), you have
a local cache of history.  That turned out to be a bad idea.  To the
extent that you actually use the local cache, it turns out to be a
quite different workflow from the (lightweight) checkout in practice.
Some people are still fans of bound branches, but it's a specialized
workflow.  The general trend is away from them.

The "heavyweight checkout" terminology is severely deprecated, and you
won't see it on bzr channels any more.

Re: bzr repository ready?

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[snip]

>  > So checkouts and branches are mostly the same?
>
> No.  In principle, a checkout is not a branch at all.  It contains the
> working tree, but no history, and by default only enough metadata to
> tell bzr which repository to get history and other metadata from.
> Since the parent repository may be on another host, "log", "diff", and
> "commit" become expensive operations, and pull and push are no-ops.

Stephen missed a word here. What he says is correct for a *lightweight*
checkout. A normal checkout contains all the metadata, and in essence
what distinguishes it from a normal branch is that every `commit' has an
implicit `push'. Normal checkouts are also known as bound branches. You
can turn a branch into a checkout and vice-versa anytime. You can also
commit to a checkout using a flag for not executing the `push'.

For all practical effects, a lightweight checkout is a CVS checkout.

[snip]

-- 
Óscar Fuentes
Desarrollo de Software

Re: bzr repository ready?

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Stephen missed a word here.

If you like.  As I understand it, however, the *idea* of a checkout is
to depend on the parent branch for history and metadata, and the
"heavyweight" checkout was actually sort of an implementation
accident: it was simplest to start by implementing checkouts as a
command which automatically bound the new branch to its parent, and
the "ideal" (lightweight) checkout was implemented later.

 > What he says is correct for a *lightweight* checkout. A normal
 > checkout contains all the metadata, and in essence

Please refer to the recent bazaar@canonical.com archives.  "Checkout"
in discussion there now means "lightweight checkout".  Ian Clatworthy
is ready to flip to lightweight by default at any time, and he even
wants bound branches to disappear entirely AFAICT.  Aaron Bentley and
Barry Warsaw talk about the "checkouts" used to implement the pipeline
plugin, etc, which are definitely lightweight.  And so on.

It is true that as of v2.0.1, 'bzr help' still refers to "normal
checkouts" (== bound branches) and --lightweight is required to get a
lightweight checkout, but it is clear that the trend is bipolar:
(unbound) branches for decentralized workflows, and (lightweight)
checkouts for centralized workflows and special applications (like
"build-only").  I think it's better to follow the modern terminology
here on emacs-devel.

Re: bzr repository ready?

[Óscar Fuentes]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

> Óscar Fuentes writes:
>
>  > Stephen missed a word here.
>
> If you like.
[snip]

>  > What he says is correct for a *lightweight* checkout. A normal
>  > checkout contains all the metadata, and in essence
>
> Please refer to the recent bazaar@canonical.com archives.  "Checkout"
> in discussion there now means "lightweight checkout".
[snip]

> It is true that as of v2.0.1, 'bzr help' still refers to "normal
> checkouts" (== bound branches) and --lightweight is required to get a
> lightweight checkout, but it is clear that the trend is bipolar:
> (unbound) branches for decentralized workflows, and (lightweight)
> checkouts for centralized workflows and special applications (like
> "build-only").  I think it's better to follow the modern terminology
> here on emacs-devel.

As you say, the terminology is redundant, and hence confusing. But as
people here will base his practice on the current bzr interface and help
files rather than on discussions on the bzr ml, IMHO it is more
appropriate to be consistent with that. People could be surprised when
they find that

bzr checkout

does not create what you call a checkout, but a bound branch.

Besides, bound branches are perfectly ok on a centralized workflow when
you are not on the local network (and thus bandwidth is not all that
great) which covers the typical FOSS project. Too often, the logic
behind the decisions of bzr's core developers does not seem very sound
to me. Is as if the project were on a permanent experimental phase,
where you can make an occassional blunder without dire consequences.

-- 
Óscar

Re: bzr repository ready?

[Richard Stallman]

    No.  In principle, a checkout is not a branch at all.  It contains the
    working tree, but no history, and by default only enough metadata to
    tell bzr which repository to get history and other metadata from.
    Since the parent repository may be on another host, "log", "diff", and
    "commit" become expensive operations, and pull and push are no-ops.

In a checkout, what do you get in the way of change log information?
I saw this

    Then you cd to your local copy of the mainline branch, merge that
    branch into it, and push to the public repo.  By default bzr log will
    show only that the whole branch got merged, but someone who is curious
    can see the detailed history.

So there is the brief info that you get with `bzr log', and the full info
you can see somehow.  Does the lightweight checkout include either of these?

Re: bzr repository ready?

[Stephen J. Turnbull]

Richard Stallman writes:

 > In a checkout, what do you get in the way of change log information?

You get the ChangeLog files, and if you are connected to the parent
branch (either on a local disk or a remote host), you can use bzr to
get the log and other information about history (eg, diffs) from the
parent branch.  This caveat about being connected is why I recommend
that core developers use branches, at least until they decide they
need to optimize space or something.

 > So there is the brief info that you get with `bzr log', and the full info
 > you can see somehow.  Does the lightweight checkout include either of these?

No, AFAIK -- it needs to talk to the parent branch.  That's why it's
"lightweight".

Re: bzr repository ready?

[Stefan Monnier]

>> > A non lightweight checkout supports committing changes without sending
>> > them to the parent branch, using a command line option.
>> When and why would this be useful?
> It's useful for splitting your history into bite-size, coherent pieces
> that you aren't ready to push to the mainline.  For example, you might
> add an argument to foofunc in foo.el, and fix all the calls in core
> Lisp.  Now you commit.  Next you go through all the packages, and fix
> them up too, with a separate commit to each one, because you're not as
> sure you understand the code in each one.  This allows you to add a
> comment explaining your uncertainty to the commit log, or have the
> package's principal maintainer veto that commit only while everything
> else goes through.
> Then you cd to your local copy of the mainline branch, merge that
> branch into it, and push to the public repo.  By default bzr log will
> show only that the whole branch got merged, but someone who is curious
> can see the detailed history.

Note that in my experience bzr's support for "local commit without
sending upstream" in bound branches (aka heavyweight checkouts) is poor,
and you may get confusing results.  So I think that if you want to do
that you'll probably be better off using a non-bound branch.
You can tempoarily do that:

   bzr unbind
   ..do all the work locally..
   bzr commit
   ..some more work...
   bzr commit
   ..some more work...
   bzr commit
   <now I'm happy>
   bzr push
   <now if I want and can revert to a bound branch>
   bzr bind

Cases where it's useful as well is when you can't commit upstream
because you don't have an internet connection.

>> Would a lightweight checkout from the master repository be a good idea
>> for people who do not intend to send patches, just build the current
>> development version?
> Yes.  I take back what I wrote in my previous response; this is indeed
> an *excellent* third reason for lightweight checkouts, probably much
> more important than "casual contribution".

Note that a lightweight checkout will make pretty much all bzr commands
slower because they'll always have to contact the repository.


        Stefan

Re: bzr repository ready?

[Chong Yidong]

Karl Fogel <kfogel@red-bean.com> writes:

> I've already written http://www.emacswiki.org/emacs/BzrForEmacsDevs.
> My instinct is to start with that, and then answer questions here as as
> people have them, rather than write lots more text only to discover that
> it doesn't answer the questions that actually come up.

Thanks for writing that page.  I noticed that the instructions are given
in terms of terminal commands (bzr merge, bzr push, etc.)  It would be
nice to have the vc/vc-dir workflow explicitly spelt out too.  Will `C-x
v v' just do the right thing with respect to committing to the local
mirror vs the global repository?

Re: bzr repository ready?

[Karl Fogel]

Chong Yidong <cyd@stupidchicken.com> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>> I've already written http://www.emacswiki.org/emacs/BzrForEmacsDevs.
>> My instinct is to start with that, and then answer questions here as as
>> people have them, rather than write lots more text only to discover that
>> it doesn't answer the questions that actually come up.
>
> Thanks for writing that page.  I noticed that the instructions are given
> in terms of terminal commands (bzr merge, bzr push, etc.)  It would be
> nice to have the vc/vc-dir workflow explicitly spelt out too.  Will `C-x
> v v' just do the right thing with respect to committing to the local
> mirror vs the global repository?

I don't know.  I don't use vc anymore (it failed to DTRT too often for
me over the last many years, so I finally decided just using an Emacs
shell buffer was more reliable; I hear vc is better now, though).

If someone who uses vc with bzr could expand the instructions, that
would be great!

Re: bzr repository ready?

[Óscar Fuentes]

Chong Yidong <cyd@stupidchicken.com> writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>
>> I've already written http://www.emacswiki.org/emacs/BzrForEmacsDevs.
>> My instinct is to start with that, and then answer questions here as as
>> people have them, rather than write lots more text only to discover that
>> it doesn't answer the questions that actually come up.
>
> Thanks for writing that page.  I noticed that the instructions are given
> in terms of terminal commands (bzr merge, bzr push, etc.)  It would be
> nice to have the vc/vc-dir workflow explicitly spelt out too.  Will `C-x
> v v' just do the right thing with respect to committing to the local
> mirror vs the global repository?

I realize that your question is just an example of something that you
want to see documented (the answer is that "it depends": if you are
working on a checkout of the global repository, the yes, the changes
go straight to it on each commit, as is the case for CVS; if you are
working on a proper branch or on a checkout or your local mirror, then
the answer is no, a `push' (most likely after `merge') is required.

I see no functions on vc/vc-dir for `push' nor for `merge'. Everytime I
need to do those, I switch to the command line.

-- 
Óscar

Re: bzr repository ready?

[Richard Stallman]

    I see no functions on vc/vc-dir for `push' nor for `merge'. Everytime I
    need to do those, I switch to the command line.

It seems that these features ought to be added to vc-dir.

Re: bzr repository ready?

[Stefan Monnier]

> Thanks for writing that page.  I noticed that the instructions are given
> in terms of terminal commands (bzr merge, bzr push, etc.)  It would be
> nice to have the vc/vc-dir workflow explicitly spelt out too.  Will `C-x
> v v' just do the right thing with respect to committing to the local
> mirror vs the global repository?

Currently VC's support for DVCS is too limited for such uses, in my
opinion.  If you're working on a leightweight checkout or a bound branch
(aka heavyweight checkout), then you can commit from VC and it will be
like a CVS commit, but further than that, VC lacks support for "pull"
and things like that, although again for the particular case of the
above checkouts, it may be able to fetch updates from the
central repository (via "bzr update").  ;-)

VC needs some love in this area.


        Stefan

Re: bzr repository ready?

[Stephen J. Turnbull]

Karl Fogel writes:

 > My sympathies -- I came to bzr from the centralized-vc world too.  It's
 > actually not that hard though.  You just have to separate the concept of
 > "checkpoint my work" from the concept of "publish my work".  In
 > centralized vc, these are unified in the "commit" command.  In Bazaar,
 > "commit" means "checkpoint" and "push" means "publish" (roughly speaking).

Darcs has the best terminology: "record" (instead of "checkpoint"
which has unnecessary connotations), and just "push" for "push" (since
centralized VCSes invariably use "commit" for record + push).

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: jearl@notengoamigos.org,  ian.clatworthy@canonical.com,  emacs-devel@gnu.org
> Date: Fri, 20 Nov 2009 14:22:28 -0500
> 
> My sympathies -- I came to bzr from the centralized-vc world too.  It's
> actually not that hard though.  You just have to separate the concept of
> "checkpoint my work" from the concept of "publish my work".  In
> centralized vc, these are unified in the "commit" command.  In Bazaar,
> "commit" means "checkpoint" and "push" means "publish" (roughly speaking).

(Actually, what I wrote about my ignorance was a lie, to some extent.
I did read Bazaar docs and related discussions before.  But I didn't
want to present only my personal problem, I wanted us to have a
tutorial that would be useful for others as well.)

> I've already written http://www.emacswiki.org/emacs/BzrForEmacsDevs.

Thanks.  I spent a couple of hours reading through it and related
docs.  Some comments:

 . The description starts with "bzr init-repo" followed by "bzr
   branch", but in fact all the discussions on the subject I saw till
   now recommend to "scp -r" instead.  It is unclear whether any of
   the first commands should be modified, replaced, or removed if the
   "scp -r" method is used.

 . http://doc.bazaar-vcs.org/latest/en/tutorials/centralized_workflow.html
   suggests to begin with "bzr whoami", but your description doesn't.
   Is it an omission, or "bzr whoami" is not required?  Any other
   useful configurations-related hints?

   Also, the above doc.bazaar URL uses the --trees switch to init-repo.
   What is its significance, and do we need to use it?

 . The suggested commands use some file names without describing their
   significance, if there is one.  Examples include trunk/ and dev/ --
   is there any reason to keep these precise names, or is it up to me?
   Also, the "cd" commands seem to indicate that all the directories
   should be under a single parent, like this:

          ROOT
               emacs
                     trunk
                     dev
                     SOME-TASKNAME

   Is this structure imposed by Bazaar or known conveniences, or is
   it just a suggestion, and the directories can be anywhere?

 . The considerations for starting a "task branch" as opposed to a
   lightweight branch are not clear.  The text talks about "multiple
   commits and rounds of feedback", but keeps silent about what does
   this "feedback" mean in practice.  More details are needed to make
   the "lightweight vs task branch" decision in practice.

 . The description of pushing local changes upstream say nothing about
   the ChangeLog files.  IIUC, unless I do something special, all my
   local log entries get to the upstream log files verbatim, and
   therefore (a) will be out of time-line (i.e. dates will not
   increase monotonically anymore), and (b) will include entries about
   intermediate changes we generally didn't want to see up until now,
   such as changes in functions that were subsequently deleted, or
   changes in functions that didn't exist on the trunk before local
   changes were pushed.  Unless there's some magic here that does TRT,
   I think we need instructions for this area.

 . The text says to update the mirror only _after_ pushing the local
   changes from the task branch and deleting that branch.  Is it not
   possible or advisable to update the mirror with partially pushed
   changes, while the task branch still exists?  (Use-case: while
   working on a new feature, I discover a bug in the existing code,
   and want to fix it without waiting for my final push.)

 . It's unclear whether building inside the mirror branch tree is okay
   or not.  For that matter, it's unclear whether the ``thing''
   created by "bzr branch" is just a simple directory tree, like the
   one created by "cvs checkout" (in which case one can build from
   within that tree), or something with more complex metadata, which
   makes building and editing in it undesirable.

 . There are still TBDs in the tutorial, in several important areas.
   The one for one-time contributors seems the most important one.

> > For each one of these, it would be enough to point to the relevant
> > sections of the existing bzr docs, no need to rewrite them, unless
> > some of the issues are mal-documented.
> 
> The above has a link to the Bazaar Users Guide, and other things.

I meant specific links to specific portions of the user guide, where
it describes in more details the individual parts of the workflow you
are describing.

> > In addition, some guidelines for selecting the right version of bzr
> > that should be installed, and if there are more than one that's
> > suitable, a short list of advantages and disadvantages of each of
> > them.
> 
> A version recommendation is already at the above link.

Yes, but it just says "1.17 or higher", to support some unnamed
features needed for Emacs.  Current versions of Bazaar are 2.0.2 and
2.1.0b1.  It would be good to have recommendations for the best
version since 1.17.

> > Finally, some guidance for users on Windows, if there are any issues
> > that need special attention (EOL format comes to mind, as well as
> > binary files, but maybe there's more).
> 
> That I can't help with (Windows-free since 1992), but there are plenty
> of Bazaar Windows users and an active user community in general.  See
> http://bazaar-vcs.org/ for details.

Are there some more focused pointers?  I couldn't find any
Windows-specific information on that page, or on first-level pages
linked from it.  What bothers me the most is the required setup of SSH
(since Bazaar evidently uses SFTP, or needs to use it to access the
master repository on subversions).  Any pointers for that?

Also, the merits and demerits of the two possible Windows installation
methods (either install Python and all the bzr dependencies manually,
then install bzr using a Python installer; or install the full bundle)
are not clear.  It sounds like the second one is faster and simpler,
but does not support easy uninstall when one wants to upgrade to a
newer version of bzr, is that right?

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[large snip]

>> > Finally, some guidance for users on Windows, if there are any issues
>> > that need special attention (EOL format comes to mind, as well as
>> > binary files, but maybe there's more).

AFAIK, bzr does not EOL handling at all. All files are binary on this
aspect. For true binary files, I don't know much about how bzr handles
them. There is this FAQ:

http://bazaar-vcs.org/FAQ#Are binary files handled?

which hints that it does basic detecting and handling.

>> That I can't help with (Windows-free since 1992), but there are plenty
>> of Bazaar Windows users and an active user community in general.  See
>> http://bazaar-vcs.org/ for details.
>
> Are there some more focused pointers?  I couldn't find any
> Windows-specific information on that page, or on first-level pages
> linked from it.  What bothers me the most is the required setup of SSH
> (since Bazaar evidently uses SFTP, or needs to use it to access the
> master repository on subversions).  Any pointers for that?

Setting up putty's pageant is easy and resolves the sftp/ssh issue
nicely. bzr will detect its presence and use it automatically.

> Also, the merits and demerits of the two possible Windows installation
> methods (either install Python and all the bzr dependencies manually,
> then install bzr using a Python installer; or install the full bundle)
> are not clear.  It sounds like the second one is faster and simpler,
> but does not support easy uninstall when one wants to upgrade to a
> newer version of bzr, is that right?

Definitely, the full bundle shall be the recommended on, unless you are
an experienced Python user which is familiarized with locating and
installing Python libraries.

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Sat, 21 Nov 2009 17:10:15 +0100
> 
> For true binary files, I don't know much about how bzr handles
> them. There is this FAQ:
> 
> http://bazaar-vcs.org/FAQ#Are binary files handled?
> 
> which hints that it does basic detecting and handling.

If someone wants to read that, the correct URL is

   http://bazaar-vcs.org/FAQ#Are%20binary%20files%20handled?

Re: bzr repository ready?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar_Fuentes <ofv@wanadoo.es>
>> Date: Sat, 21 Nov 2009 17:10:15 +0100
>> 
>> For true binary files, I don't know much about how bzr handles
>> them. There is this FAQ:
>> 
>> http://bazaar-vcs.org/FAQ#Are binary files handled?
>> 
>> which hints that it does basic detecting and handling.
>
> If someone wants to read that, the correct URL is
>
>    http://bazaar-vcs.org/FAQ#Are%20binary%20files%20handled?

Actually it is
<http://bazaar-vcs.org/FAQ#Are%20binary%20files%20handled%3F>.

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."

Re: bzr repository ready?

[Stefan Monnier]

>  . The description starts with "bzr init-repo" followed by "bzr
>    branch", but in fact all the discussions on the subject I saw till
>    now recommend to "scp -r" instead.  It is unclear whether any of
>    the first commands should be modified, replaced, or removed if the
>    "scp -r" method is used.

Yes, the "scp -r" does the "init-repo" plus fetches the branches.
What it doesn't do is "check out" the branches, i.e. populate the
directories with the files of the branches.  So you need something like:

  scp -r bzr.sv.gnu.org:/srv/bzr/emacs .
  cd emacs/trunk; bzr checkout
  bzr pull sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk

IIUC scp only works for non-anonymous access, so we'll want to place
a tarball somewhere for download so the scp will be replaced by
"wget+untar".

>    Also, the above doc.bazaar URL uses the --trees switch to init-repo.
>    What is its significance, and do we need to use it?

IIRC it means that when you do "bzr branch" (aka "bzr clone") you'll get
a branch complete with its files, whereas otherwise you'd only get
a branch without its files (i.e. it would require a separate "bzr
checkout" as I did above in order to get the files).

>    Is this structure imposed by Bazaar or known conveniences, or is
>    it just a suggestion, and the directories can be anywhere?

Just a suggestion.  Emacs's own repository uses "trunk" for the main
line of development, so it makes sense to use the same name, but it
doesn't have to be the case either.

>  . The considerations for starting a "task branch" as opposed to a
>    lightweight branch are not clear.  The text talks about "multiple
>    commits and rounds of feedback", but keeps silent about what does
>    this "feedback" mean in practice.  More details are needed to make
>    the "lightweight vs task branch" decision in practice.

For any kind of development, I strongly discourage lightweight branches,
unless you have very fast and constant access to the base repository
(i.e. most likely not the case if the base repository is the Emacs
repository).

>  . The description of pushing local changes upstream say nothing about
>    the ChangeLog files.  IIUC, unless I do something special, all my
>    local log entries get to the upstream log files verbatim, and
>    therefore (a) will be out of time-line (i.e. dates will not
>    increase monotonically anymore), and (b) will include entries about
>    intermediate changes we generally didn't want to see up until now,
>    such as changes in functions that were subsequently deleted, or
>    changes in functions that didn't exist on the trunk before local
>    changes were pushed.  Unless there's some magic here that does TRT,
>    I think we need instructions for this area.

There's no magic.  Since we will still use the ChangeLog file, that file
will need to be written (or at least fixed up) at the time you push to
upstream).

>  . The text says to update the mirror only _after_ pushing the local
>    changes from the task branch and deleting that branch.  Is it not
>    possible or advisable to update the mirror with partially pushed
>    changes, while the task branch still exists?  (Use-case: while
>    working on a new feature, I discover a bug in the existing code,
>    and want to fix it without waiting for my final push.)

No idea.

>  . It's unclear whether building inside the mirror branch tree is okay
>    or not.  For that matter, it's unclear whether the ``thing''
>    created by "bzr branch" is just a simple directory tree, like the
>    one created by "cvs checkout" (in which case one can build from
>    within that tree), or something with more complex metadata, which
>    makes building and editing in it undesirable.

It's just like a cvs checkout in this respect.

> Yes, but it just says "1.17 or higher", to support some unnamed
> features needed for Emacs.  Current versions of Bazaar are 2.0.2 and
> 2.1.0b1.  It would be good to have recommendations for the best
> version since 1.17.

I think "1.17 or higher" is about as good as it gets.  More recent
versions will give you more recent code with new features and new bugs,
of course, but I don't think there's any preferred version.  Of course
if you have to download one, you might as well download the latest
stable version.


        Stefan

Re: bzr repository ready?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Karl Fogel <kfogel@red-bean.com>,  jearl@notengoamigos.org,  ian.clatworthy@canonical.com,  emacs-devel@gnu.org
> Date: Sun, 22 Nov 2009 15:55:05 -0500
> 
> >  . The considerations for starting a "task branch" as opposed to a
> >    lightweight branch are not clear.  The text talks about "multiple
> >    commits and rounds of feedback", but keeps silent about what does
> >    this "feedback" mean in practice.  More details are needed to make
> >    the "lightweight vs task branch" decision in practice.
> 
> For any kind of development, I strongly discourage lightweight branches,
> unless you have very fast and constant access to the base repository
> (i.e. most likely not the case if the base repository is the Emacs
> repository).

I think this is a misunderstanding: I was talking about lightweight
checkouts from the local repository, not from the remote one.  I hope
it's not my misunderstanding.

Re: bzr repository ready?

[Stefan Monnier]

>> For any kind of development, I strongly discourage lightweight branches,
>> unless you have very fast and constant access to the base repository
>> (i.e. most likely not the case if the base repository is the Emacs
>> repository).

> I think this is a misunderstanding: I was talking about lightweight
> checkouts from the local repository, not from the remote one.  I hope
> it's not my misunderstanding.

Sorry, you're right.  Lightweight checkouts from a local repository are
perfectly fine and very useful indeed (e.g. for "bzr switch" style
uses).


        Stefan

Re: bzr repository ready?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>  . The description starts with "bzr init-repo" followed by "bzr
>>    branch", but in fact all the discussions on the subject I saw till
>>    now recommend to "scp -r" instead.  It is unclear whether any of
>>    the first commands should be modified, replaced, or removed if the
>>    "scp -r" method is used.
>
> Yes, the "scp -r" does the "init-repo" plus fetches the branches.
> What it doesn't do is "check out" the branches, i.e. populate the
> directories with the files of the branches.  So you need something like:
>
>   scp -r bzr.sv.gnu.org:/srv/bzr/emacs .
>   cd emacs/trunk; bzr checkout
>   bzr pull sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk

I think you are partially wrong on this. With the scp you are cloning
(in the filesystem meaning) the directory where the GNU emacs repository
lives. This includes all branches, which means all VC metadata (history,
etc). I guess that the administrators used the --no-trees option when
they created the repository.

So you get all what you need including the files, it is just that they
are stored with the metadata and not visible/usable yet. Try this:

# Get a copy of the GNU repo:
$ scp -r bzr.sv.gnu.org:/srv/bzr/emacs
# Create a work branch:
$ cd emacs
$ bzr branch trunk work

The new branch `work' will contain all the files. The `pull' you do at
the end is unnecessary because you already have the most recent data
from the repository.

Your recipe is the right one for testing the CVS->bzr conversion (check
that all CVS branches and tags are there, etc). But for hacking, IMO scp
is highly discouraged, as there is no guarantee that you obtain the
repository on a consitent state and it may completely fail if the
administrators fuse the emacs repo into a global bzr repo for all GNU
projects. Besides, you usually are interested on one or two branches,
not on the whole repository.

So for hacking the best thing is to

# Initialize a shared repository:
$ bzr init-repo emacs-dev
$ cd emacs-dev
# Get the branch you are interested on:
$ bzr branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk
# Now you have everything you need on the `trunk' directory, including
# files ready to be edited. But you'll better leave it as a mirror of
# the branch on GNU and work elsewhere:
$ bzr branch trunk work
# Use `work` for hacking.

Note: the `bzr init-repo' assumes that you are working with the latest
stable bzr release (2.0) For previous versions, you maybe need

$ bzr init-repo --rich-root

or some other variant.

Really, now that 2.0 is out for some time, I see no reason for not
recommending it and deprecate previous versions. We are having
difficulties due to the multitude of supported workflows, and supporting
past bzr versions will only create more confussion.

>   bzr pull sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk

> IIUC scp only works for non-anonymous access, so we'll want to place
> a tarball somewhere for download so the scp will be replaced by
> "wget+untar".

Please note that the tarball method gives you the state of the project
at the time it was made, but of course you want to update your files
whenever necessary. For that you need read-only access to the
repository. If you can give http access to bzr.sv.gnu.org/srv/bzr/emacs,
forget about the tarballs and be done with that.

>>    Also, the above doc.bazaar URL uses the --trees switch to init-repo.
>>    What is its significance, and do we need to use it?
>
> IIRC it means that when you do "bzr branch" (aka "bzr clone") you'll get
> a branch complete with its files, whereas otherwise you'd only get
> a branch without its files (i.e. it would require a separate "bzr
> checkout" as I did above in order to get the files).

By default, you get a working tree (the files you work on), so "--trees"
is redundant. You have --no-tree (branch command) and --no-trees
(init-repo command) for explicitly requiring from bzr that it should not
create working trees (the actual files you edit on).

[snip]

> For any kind of development, I strongly discourage lightweight branches,
> unless you have very fast and constant access to the base repository
> (i.e. most likely not the case if the base repository is the Emacs
> repository).

Right.

[snip]

>>  . The text says to update the mirror only _after_ pushing the local
>>    changes from the task branch and deleting that branch.  Is it not
>>    possible or advisable to update the mirror with partially pushed
>>    changes, while the task branch still exists?  (Use-case: while
>>    working on a new feature, I discover a bug in the existing code,
>>    and want to fix it without waiting for my final push.)

There is no such thing as "partially pushed changes". `push' is an
atomic operation that sends a series of commits (by default, those who
were not pushed yet) to some other branch. You can push changes whenever
you please, and pull changes likewise.

The use-case you mention is better solved with a feature branch. For
instance:

# Suppose you are working on my-feature branch/directory:
$ cd ..
$ bzr branch trunk bug-fix
$ cd bug-fix
...edit...
$ bzr commit -m "Fixed blah"
$ bzr push sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk
$ cd ../my-feature
# Incorporate your bug-fix into your work:
$ bzr merge --force ../bug-fix
# The --force option is in case you have uncommitted changes on your
# branch. It is advisable to not merge upon modified (edited &
# ucommitted) files, for not mixed the merged changes with your
# modifications.
# Commit the merged changes:
$ bzr commit file -m "Merged bug-fix"
... keep hacking on your feature ...

You could have a branch for that kind of work, instead of creating one
each time.

[snip]

-- 
Óscar

Re: bzr repository ready?

[Stefan Monnier]

>> scp -r bzr.sv.gnu.org:/srv/bzr/emacs .
>> cd emacs/trunk; bzr checkout
>> bzr pull sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk

> I think you are partially wrong on this. With the scp you are cloning
> (in the filesystem meaning) the directory where the GNU emacs repository
> lives. This includes all branches, which means all VC metadata (history,
> etc).

Yes, that's right.  I don't thin kI implied otherwise.

> I guess that the administrators used the --no-trees option when
> they created the repository.

Could be.  But it's not relevant to the above example.

> The `pull' you do at the end is unnecessary because you already have
> the most recent data from the repository.

The purpose is not to get the most recent data.  It's two fold:
1- to set the .bzr/branch/branch.conf's parent_branch.
2- so that the same recipe can be used if you download a tarball (just
   eplace the scp with wget+untar), in which case the pull will be
   useful to download the latest revision.

> Your recipe is the right one for testing the CVS->bzr conversion (check
> that all CVS branches and tags are there, etc). But for hacking, IMO scp
> is highly discouraged, as there is no guarantee that you obtain the
> repository on a consitent state

That's a good point.  Really we'll want to recommend the wget+untar
recipe and avoid the scp alotogether.

> and it may completely fail if the administrators fuse the emacs repo
> into a global bzr repo for all GNU projects.

Don't worry about this.  It wouldn't make any sense whatsoever.

> Besides, you usually are interested on one or two branches,
> not on the whole repository.

The time it takes to "bzr clone" a single branch from the Emacs
repository is many times larger than downloading the tarball containing
every single banch.

Actually, the Emacs history doesn't have many branches, so there really
is little difference between "just the trunk" and "everything under the
sun".

> So for hacking the best thing is to

> # Initialize a shared repository:
> $ bzr init-repo emacs-dev
> $ cd emacs-dev
> # Get the branch you are interested on:
> $ bzr branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk

Even with a very fast connection to the internet, this step takes ages.
Given the current state of Bzr optimization, I don't think we should
impose this kind of hassle on our potential contributors.  That's why
the current plan is to offer a tarball which could be updated once
a month or so.

> Please note that the tarball method gives you the state of the project
> at the time it was made, but of course you want to update your files
> whenever necessary. For that you need read-only access to the
> repository. If you can give http access to bzr.sv.gnu.org/srv/bzr/emacs,
> forget about the tarballs and be done with that.

There is http access already: http://bzr.savannah.gnu.org/r/emacs
But again, the problem is the inefficiency of Bzr.


        Stefan

Re: bzr repository ready?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[snip]

>> The `pull' you do at the end is unnecessary because you already have
>> the most recent data from the repository.
>
> The purpose is not to get the most recent data.  It's two fold:
> 1- to set the .bzr/branch/branch.conf's parent_branch.

You'll better use

bzr pull --remember sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk
         ^^^^^^^^^^

just in case the branch already has `pull branch' (not to confuse with
the parent branch, for setting this you need to edit a configuration
file under the .bzr directory of the branch, IIRC). After all, you are
copying raw files and can't assume a lot about the configuration of the
branches you are obtaining.

The operation should be done for each branch on the repo (using the
correct URL to the remote branch), because `bzr pull', as almost every
other command, works on only one branch.

[snip]

>> Besides, you usually are interested on one or two branches,
>> not on the whole repository.
>
> The time it takes to "bzr clone" a single branch from the Emacs
> repository is many times larger than downloading the tarball containing
> every single banch.

Uh, I forgot how much `bzr branch' sucks for cloning large branches
across the internet.

[snip]

-- 
Óscar

Re: bzr repository ready?

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>> Besides, you usually are interested on one or two branches,
>>> not on the whole repository.
>>
>> The time it takes to "bzr clone" a single branch from the Emacs
>> repository is many times larger than downloading the tarball containing
>> every single banch.
>
> Uh, I forgot how much `bzr branch' sucks for cloning large branches
> across the internet.

Just checked again:

oscar@qcore:~/dev/other/$ bzr init-repo bzr-emacs
oscar@qcore:~/dev/other/$ cd bzr-emacs
oscar@qcore:~/dev/other/bzr-emacs$ time bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk
Branched 98737 revision(s).

real    22m59.636s
user    9m49.320s
sys     0m5.440s

then cloned another branch:

oscar@qcore:~/dev/other/bzr-emacs$ time bzr branch http://bzr.savannah.gnu.org/r/emacs/multi-tty
Branched 77736 revision(s).

real    2m15.748s
user    0m8.280s
sys     0m1.010s

It could be much better, but it is not unreasonable for an operation
that you need to do only once.

The most frustrating part of the cloning process is that the progress
info that bzr gives is pretty much useless, so the user has no clue
about how much time it will take.

I used bzr 2.0 on Kubuntu 9.10 x86_64, with an Intel Q6600 CPU 2.4 GHz,
8 GB RAM, ADSL 6 Mb/s (max download speed ~ 620 KB/s), ext3 filesystem,
python 2.6.4.

bzr dowloaded approx. 260 MB of data and took 10 minutes of CPU time for
the first clone using just a little bit more than 1 GB of RAM.

What took a really long time for such a simple operation was

oscar@qcore:~/dev/other/bzr-emacs$ time bzr branches http://bzr.savannah.gnu.org/r/emacs
Boehm-GC                                                                                
Boehm-versions                                                                          
DAVELOVE                                                                                
EMACS_21_1_RC                                                                           
EMACS_22_BASE                                                                           
EMACS_23_1_RC                                                                           
FLYSPELL                                                                                
ILYA                                                                                    
NewVC-fileset
URL
VENDOR
XFT_JHD_BRANCH
branch-5_8
cedet-branch
custom_themes
emacs-bidi
emacs-unicode
emacs-unicode-2
font-backend
fx-branch
gerd_big
gerd_dbe
gerd_defvaralias
glibc-2_0_x
gnus-5_10-branch
lexbind
master-UNNAMED-BRANCH
multi-tty
patches_21_0
rmail-mbox-branch
test2
trunk
ttn-vms-21-2-stash
ttn-vms-21-3-stash
unicode-xft

real    5m19.574s
user    0m1.290s
sys     0m0.070s

BTW, there is quite a bit of junk there. Including all that stuff on a
tarball can confuse newcomers, or at least force them to do some work
cleaning their local repository.

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,
> 	UNPARSEABLE_RELAY autolearn=unavailable version=3.1.0
> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Mon, 23 Nov 2009 05:34:26 +0100
> 
> oscar@qcore:~/dev/other/$ bzr init-repo bzr-emacs
> oscar@qcore:~/dev/other/$ cd bzr-emacs
> oscar@qcore:~/dev/other/bzr-emacs$ time bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk
> Branched 98737 revision(s).
> 
> real    22m59.636s
> user    9m49.320s
> sys     0m5.440s

That's not very long: a full CVS checkout of the trunk took me 16
minutes of real time.

Re: bzr repository ready?

[Glenn Morris]

Karl Fogel wrote:

> I've already written http://www.emacswiki.org/emacs/BzrForEmacsDevs.
> My instinct is to start with that, and then answer questions here as as
> people have them, rather than write lots more text only to discover that
> it doesn't answer the questions that actually come up.

That seems fine, but please do summarize the answers to the questions
that people ask in a document somewhere. Trawling through a bunch of
mailing list posts to figure out how to do something is not ideal.

Re: bzr repository ready?

[Karl Fogel]

Glenn Morris <rgm@gnu.org> writes:
>> I've already written http://www.emacswiki.org/emacs/BzrForEmacsDevs.
>> My instinct is to start with that, and then answer questions here as as
>> people have them, rather than write lots more text only to discover that
>> it doesn't answer the questions that actually come up.
>
> That seems fine, but please do summarize the answers to the questions
> that people ask in a document somewhere. Trawling through a bunch of
> mailing list posts to figure out how to do something is not ideal.

Feel free!

Indulging in the passive voice: FAQs should be collected, especially
once the switchover takes place, and either incorporated in the above
document or into a separate "Bzr for Emacs" FAQ.

I'm not volunteering to do it all.  We should do it collectively.  If
"do it collectively" doesn't work, then we've got a problem, and I'm not
promising to be the one to solve that problem :-).

(I am not a Bazaar expert; I'm just a regular user who likes it a lot.
I'm pretty sure that many people participating in this thread actually
know more about Bazaar than I do.  I'll answer what I can, of course,
but it would be bad if I were the primary resource.)

Right now, the only question that's come up that I think belongs in that
document is "What should be the standard workflow for Emacs developers
in Bazaar?"  That's a question we already had a draft answer for, and
Stephen Turnbull has since improved it (I'm about to review it).

-Karl

Re: bzr repository ready?

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

[snip]

> Right now, the only question that's come up that I think belongs in that
> document is "What should be the standard workflow for Emacs developers
> in Bazaar?"

The issue here is that the emacs developers are very heterogenous and
bzr supports lots of workflows, so it is difficult to set standards
here.

Jason just showed how simple is to mimic the CVS workflow with bzr, with
the added benefit of avoiding the net for expensive operations like log,
annotate, etc.

IMHO it is a good basis to start. The adventurous among the emacs
hackers will learn by themselves (or with some help from others) how to
get more juice from bzr. The most conservative will see how others do
and eventually recognize and master those features that best fit them.

[snip]

-- 
Óscar

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  jearl@notengoamigos.org,  ian.clatworthy@canonical.com,  emacs-devel@gnu.org
> Date: Sun, 22 Nov 2009 17:41:47 -0600
> 
> Right now, the only question that's come up that I think belongs in that
> document is "What should be the standard workflow for Emacs developers
> in Bazaar?"  That's a question we already had a draft answer for, and
> Stephen Turnbull has since improved it (I'm about to review it).

Except that alternative workflows were mentioned here since then, and
it is no longer clear to me that the one described on the Wiki is the
best one.  Perhaps we should add a few more there.

Re: bzr repository ready?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Right now, the only question that's come up that I think belongs in that
>> document is "What should be the standard workflow for Emacs developers
>> in Bazaar?"  That's a question we already had a draft answer for, and
>> Stephen Turnbull has since improved it (I'm about to review it).
>
> Except that alternative workflows were mentioned here since then, and
> it is no longer clear to me that the one described on the Wiki is the
> best one.  Perhaps we should add a few more there.

There is no "best-one" workflow. It depends on what kind of work you do,
what's your environment (i.e. connected/disconnected) and even on your
personal preferences.

People like Richard that is off-line most of the time will appreciate
the possibility of committing lots of changes to his personal repo and
send them all to the GNU repo in one batch when he gets net access. This
has the inconvenience that you allow a lot of time for the branches to
diverge and the merge you are required to do before pushing your local
commits to the GNU repo can give a bit of work, on terms of code review.

Other people that work at home doing occassional small code cleanups and
fixing typos will be happy working with bound branches (aka heavyweight
checkouts) which sends their commits to the GNU repo on the spot.

Some people will like to organize their work on feature branches. Other
less-strict personalities will do all their work on the same branch.

It is not a matter of finding the best workflow, but beginning with one
that is better than CVS and simple enough to minimize the effort,
setting a basis for introducing variations.

On this regard, the workflow that Jason described elsewhere based on
bound branches is the one we should recommend, IMHO. Once you master
that, using unbound branches is an evolutive step: you need to learn
more, but what you already know still applies.

-- 
Óscar

Re: bzr repository ready?

[Stefan Monnier]

>>> Right now, the only question that's come up that I think belongs in that
>>> document is "What should be the standard workflow for Emacs developers
>>> in Bazaar?"  That's a question we already had a draft answer for, and
>>> Stephen Turnbull has since improved it (I'm about to review it).
>> 
>> Except that alternative workflows were mentioned here since then, and
>> it is no longer clear to me that the one described on the Wiki is the
>> best one.  Perhaps we should add a few more there.

I think we should only consider setups that are close to what was done
with CVS.  After that, people can read the Bzr docs to figure out what's
best for them.


        Stefan

Re: bzr repository ready?

[Stephen J. Turnbull]

Stefan Monnier writes:

 > I think we should only consider setups that are close to what was done
 > with CVS.  After that, people can read the Bzr docs to figure out what's
 > best for them.

FSVO "close to CVS."  Specifically, I *strongly recommend* that all
workflows recommended to core developers start by creating a local
repo (try that in CVS! :-).  Questions for those who have actually
used bzr on the emacs repo (for the moment, I'm not interested in
GPLv3 code but we're working on that :-):

1.  Jason's suggestion of "bzr init-repo --no-trees -2a" sounds like a
    good idea to me for performance reasons.  Is this going to be
    entirely superseded by the "wget; tar x" workflow?

    N.B. Many projects that convert to dVCS start to proliferate
    "sandbox" branches, cf. http://code.launchpad.net/mailman/ or
    http://git.kernel.org/.  I *think* that if the same base URL is
    used to host such sandbox branches, it won't cause any problems
    for the "wget; tar x" workflow" (you just do tar c only on the
    "emacs" trunk branch).  I think it's worth planning for that
    possibility in structuring the Emacs Bazaar repository.

2.  I think that all core developer workflows we recommend *at this
    point in time in the wiki page* should start with "bzr branch
    trunk" (not usual in CVS but I think the rest of the workflow is
    reasonably close to CVS).  I recommend exactly two variants:

    a.  A generic "dev" branch for small one-off fixes.  I recommend
        the branch name "quickfixes" or something like that instead,
        to more precisely indicate the purpose of the branch.

        I would do this kind of work directly on a trunk checkout in
        CVS.

    b.  Feature branches for any work that might involve concurrent
        commits in other branches you're working on locally, or might
        span several updates from upstream.

        I would do long-running tasks with many commits on a branch in
        CVS, while relatively short tasks (which nevertheless span
        multiple updates from upstream for whatever reason) would be
        done in the trunk checkout.  The latter half I consider
        suboptimal though, and I hope people transitioning from CVS
        would find it as natural as I do to crank the threshold for
        feature branches way down.

3.  How do people organize their branches (bound or not) and
    (lightweight) checkouts?  Eg, for my desultory work on GNU
    Mailman, I have

    Mailman -+- 3.0                # all toplevel branches are mirrors
             |                     # and are configured treeless
             +- 2.2                # defunct
             |
             +- 2.1
             |
             +- work -+- 3.0       # all local branches and checkouts
                      |            # will be placed under work/
                      |            # work is an ordinary directory
                      |            # 3.0 is also registered on Launchpad[1]
                      +- lilfix    # these are both branches; "lilfix"
                                   # is a historical relic, I think
                                   # "quickfixes" is a better generic
                                   # recommendation


Footnotes: 
[1]  I don't know if "registering a branch" has a corresponding
feature on Savannah, but I thought I should mention this fact.

Re: bzr repository ready?

[Stefan Monnier]

>> I think we should only consider setups that are close to what was done
>> with CVS.  After that, people can read the Bzr docs to figure out what's
>> best for them.
> FSVO "close to CVS."  Specifically, I *strongly recommend* that all
> workflows recommended to core developers start by creating a local
> repo (try that in CVS! :-).

I consider Bzr unusable without a shared repository (just like Arch was
unusable without a "revlib"), so I fully agree.

> 1.  Jason's suggestion of "bzr init-repo --no-trees -2a" sounds like a
>     good idea to me for performance reasons.  Is this going to be
>     entirely superseded by the "wget; tar x" workflow?

I think so, yes.

>     "emacs" trunk branch).  I think it's worth planning for that
>     possibility in structuring the Emacs Bazaar repository.

You mean the main repository should not be directly at .../srv/bzr/emacs
but at .../srv/bzr/<something>/emacs ?  I think I agree.

> 2.  I think that all core developer workflows we recommend *at this
>     point in time in the wiki page* should start with "bzr branch
>     trunk" (not usual in CVS but I think the rest of the workflow is
>     reasonably close to CVS).  I recommend exactly two variants:

I can think of only 3 useful starting points:
1- lightweight checkout: for people who only want to fetch the latest
   code but will never need/want the diff/log or contribute code.
2- bound branch (aka heavyweight checkout): for people who are happy
   with CVS and will never want to create a local branch.
3- a local mirror-branch + a local dev branch.

If you want something fancier than (3), read the Bzr docs.
I'm not actually convinced that (1) and (2) are really that important,
so maybe we could drop one of them (or maybe both of them even).
But the hard part is to integrate those 3 starting points with the
"wget+untar" approach.


        Stefan

Re: bzr repository ready?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I can think of only 3 useful starting points:
> 1- lightweight checkout: for people who only want to fetch the latest
>    code but will never need/want the diff/log or contribute code.
> 2- bound branch (aka heavyweight checkout): for people who are happy
>    with CVS and will never want to create a local branch.
> 3- a local mirror-branch + a local dev branch.

This sounds as if one have to make a long-term decission.

Going from 2 to 3 and vice-versa requires less than a minute. You can
mix both workflows without problem. So don't worry too much. Start with
2 and, if you feel in the mood, upgrade to 3.

-- 
Óscar

Re: bzr repository ready?

[Stefan Monnier]

>> I can think of only 3 useful starting points:
>> 1- lightweight checkout: for people who only want to fetch the latest
>> code but will never need/want the diff/log or contribute code.
>> 2- bound branch (aka heavyweight checkout): for people who are happy
>> with CVS and will never want to create a local branch.
>> 3- a local mirror-branch + a local dev branch.

> This sounds as if one have to make a long-term decission.

> Going from 2 to 3 and vice-versa requires less than a minute.

If you have (2) without a shared repository, it can be a bit more tricky
(yes, it can still be done in less than a minute, but only if you know how).


        Stefan

Re: bzr repository ready?

[Stephen J. Turnbull]

Stefan Monnier writes:

 > >     "emacs" trunk branch).  I think it's worth planning for that
 > >     possibility in structuring the Emacs Bazaar repository.
 > 
 > You mean the main repository should not be directly at .../srv/bzr/emacs
 > but at .../srv/bzr/<something>/emacs ?  I think I agree.

I'm not entirely sure what I mean.  I've pretty well convinced myself
there's no big efficiency issue in having "sandbox" branches in with
the emacs-repo tarball, but maybe you want the tarball to omit their
directories (as well as being treeless).

 > I can think of only 3 useful starting points:
 > 1- lightweight checkout: for people who only want to fetch the latest
 >    code but will never need/want the diff/log or contribute code.

This is easy (although we haven't written it up yet).

 > 2- bound branch (aka heavyweight checkout): for people who are happy
 >    with CVS and will never want to create a local branch.

I don't think bound branches should be encouraged in Emacs.  YMMV, but
I think in most loosely organized projects they're a worst practice.

 > 3- a local mirror-branch + a local dev branch.
 > 
 > If you want something fancier than (3), read the Bzr docs.

Well, Karl already added a description of feature branching, and I've
done a bit of work on that too.  (In fact, the editorial equivalent of
open heart surgery -- as academic acknowledgments say, "any remaining
badness is all mine", you can't blame Karl.)

I'm reasonably satisfied that it would not be a waste of your time to
review it at this point (and I'm looking forward to Eli's opinion, I'm
hoping he'll find it useful).

 > I'm not actually convinced that (1) and (2) are really that important,
 > so maybe we could drop one of them (or maybe both of them even).
 > But the hard part is to integrate those 3 starting points with the
 > "wget+untar" approach.

Well, if you want that added to the wiki, it's not hard to explain how
to move any local changes from either a checkout or a branch into a
new shared repo.  I'm kinda hoping that people will follow
instructions, and not go in for target practice on their feet---it
should be unnecessary.

Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Tue, 24 Nov 2009 03:06:33 +0900
> Cc: emacs-devel@gnu.org
> 
> I'm reasonably satisfied that it would not be a waste of your time to
> review it at this point (and I'm looking forward to Eli's opinion, I'm
> hoping he'll find it useful).

It is very useful, thanks.  I have a few comments, mostly editorial,
and some questions:

   If you are a committer, you will want to use a bzr+ssh URL instead:
   bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk.

Doesn't this URL require a savannah username somewhere in it?

   This first checkout may take many minutes.

It's unclear to what command this refers: none of them mentioned any
"checkouts".

   If there are other branches you’d like to mirror ...

Question: doesn't the local repository we just created include all the
branches anyway?  Didn't someone say that the repository allows
working off-line? if so, it should include all the branches in the
master repository, no?

   Compared to CVS, these branches are lightweight — it doesn’t cost much
   to create them, as they’re all sharing storage in the repository, and
   they can’t bother anyone else. However, there is one “weighty” aspect:
   the source tree itself, which takes time to check out. Even more
   important, there will be no build products in the tree. make bootstrap
   takes an annoying amount of time. That’s why we recommend that for
   small changes you use a dedicated branch. Once you’ve bootstrapped the
   build, the update, build, and commit elements of the
   update-edit-build-test-commit cycle are all very fast.

This is confusing and looks like a merge of 2 different narratives.
Is ``dedicated branch'' what is later described as ``feature
branches'' or something else?  If the source tree is ``weighty'', then
why are the branches ``lightweight''?  Why is it important that there
will be no build products in the tree? etc. etc.  Please consider
rewriting this paragraph.

   Once you have completed the task, you’ll want to send it
   upstream. You do this just as you would for a quick fix ...

What about branches in the master repository?  Unless I'm missing
something, the described workflows don't cover that.  What if I want
to have my branch available from the upstream?  (Release branches will
need that, right?)

Finally, it looks like the TBDs near the end can be simply deleted
now, as what's before covers that turf already.

Thanks.

Re: bzr repository ready?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> It is very useful, thanks.  I have a few comments, mostly editorial,
> and some questions:
>
>    If you are a committer, you will want to use a bzr+ssh URL instead:
>    bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk.
>
> Doesn't this URL require a savannah username somewhere in it?

It's much easier to put the username in ~/.ssh/config.  But note that
bzr+ssh does not work with savannah, it only allows sftp for pushing.

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."

Re: bzr repository ready?

[Stefan Monnier]

> It's much easier to put the username in ~/.ssh/config.

Agreed.

> But note that bzr+ssh does not work with savannah, it only allows sftp
> for pushing.

That's indeed a problem that still needs fixing on the side of Savannah.


        Stefan

Re: bzr repository ready?

[Richard Stallman]

    > But note that bzr+ssh does not work with savannah, it only allows sftp
    > for pushing.

    That's indeed a problem that still needs fixing on the side of Savannah.

Is someone here talking with the Savannah hackers about fixing this?

Re: bzr repository ready?

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>     > But note that bzr+ssh does not work with savannah, it only allows sftp
>     > for pushing.
>
>     That's indeed a problem that still needs fixing on the side of Savannah.
>
> Is someone here talking with the Savannah hackers about fixing this?

https://savannah.gnu.org/support/index.php?107143

-Karl

Re: bzr repository ready?

[Stephen J. Turnbull]

Richard Stallman writes:

 >     > But note that bzr+ssh does not work with savannah, it only allows sftp
 >     > for pushing.
 > 
 >     That's indeed a problem that still needs fixing on the side of Savannah.
 > 
 > Is someone here talking with the Savannah hackers about fixing this?

Somebody also ought to check on the "service not running, try again
later" message for http://bzr.savannah.gnu.org/lh/emacs.  That's
Savannah service request sr #107142.

Re: bzr repository ready?

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> > > But note that bzr+ssh does not work with savannah, it only allows sftp 
> > > for pushing.
> > 
> > That's indeed a problem that still needs fixing on the side of Savannah.
> > 
> > Is someone here talking with the Savannah hackers about fixing this?

Regarding SR#107143, which I filed yesterday about bzr+ssh:// access:

It turns out to be a dup of SR#107077, and the full situation is
explained here: http://savannah.gnu.org/maintenance/Bzr.  Short answer:
no immediate plans to make bzr+ssh:// access available, but if we have a
good reason why we need it, then we can talk with them about it.

> Somebody also ought to check on the "service not running, try again
> later" message for http://bzr.savannah.gnu.org/lh/emacs.  That's
> Savannah service request sr #107142.

Regarding this one: I've added it to the open issues list in
http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover#References.  It's
only two days old, so the fact that there's no response yet is not
alarming, but we should hear something soon -- it's important!

-Karl

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <karl.fogel@canonical.com>
> Date: Wed, 25 Nov 2009 11:48:04 -0600
> Cc: emacs-devel@gnu.org, rms@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> Regarding SR#107143, which I filed yesterday about bzr+ssh:// access:
> 
> It turns out to be a dup of SR#107077, and the full situation is
> explained here: http://savannah.gnu.org/maintenance/Bzr.  Short answer:
> no immediate plans to make bzr+ssh:// access available, but if we have a
> good reason why we need it, then we can talk with them about it.

Then what is the alternative for people with write access to the
master repository?  Currently, bzr+ssh is listed on the wiki as the
only method for ``committers''.  I understand that people who want to
(and can) commit to the master repo need to use this access method.
Did I miss something?

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Then what is the alternative for people with write access to the
 > master repository?  Currently, bzr+ssh is listed on the wiki as the
 > only method for ``committers''.

Committers can use sftp.  I've updated the wiki.

Please understand, the wiki document is *beta* quality at best.
savannah-hackers has their way of looking at things, which clearly
does not put "effective use of Bazaar" at the top of the list.  So
we're all going to have to be patient.

Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Karl Fogel <karl.fogel@canonical.com>,
>     emacs-devel@gnu.org
> Date: Thu, 26 Nov 2009 04:26:40 +0900
> 
> Eli Zaretskii writes:
> 
>  > Then what is the alternative for people with write access to the
>  > master repository?  Currently, bzr+ssh is listed on the wiki as the
>  > only method for ``committers''.
> 
> Committers can use sftp.  I've updated the wiki.

Thanks.

Re: bzr repository ready?

[Stefan Monnier]

> It turns out to be a dup of SR#107077, and the full situation is
> explained here: http://savannah.gnu.org/maintenance/Bzr.  Short answer:
> no immediate plans to make bzr+ssh:// access available, but if we have a
> good reason why we need it, then we can talk with them about it.

The good reason is performance and bandwidth: when committing via sftp
it's not uncommon to end up transferring several MB (as in, more than
10) of data just to commit a tiny change.


        Stefan

Re: bzr repository ready?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 23 Nov 2009 23:59:42 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is very useful, thanks.  I have a few comments, mostly editorial,
> > and some questions:
> >
> >    If you are a committer, you will want to use a bzr+ssh URL instead:
> >    bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk.
> >
> > Doesn't this URL require a savannah username somewhere in it?
> 
> It's much easier to put the username in ~/.ssh/config.

Thanks.  I think this should be added to the wiki.

Re: bzr repository ready?

[Stephen J. Turnbull]

Thansk for the review, Eli!

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>

 >    If you are a committer, you will want to use a bzr+ssh URL instead:
 >    bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk.
 > 
 > Doesn't this URL require a savannah username somewhere in it?

Dunno.  Probably, but somebody who knows how Savannah works needs to
fix that up.  (Karl actually wrote that URL, but IIRC he's not a
Savannah user, either.  I bet he did what I would have done:
substitute "bzr+ssh" for "http" in the http: URL.)

 >    This first checkout may take many minutes.
 > 
 > It's unclear to what command this refers: none of them mentioned any
 > "checkouts".

Fixed on the wiki.

 >    If there are other branches you'd like to mirror ...
 > 
 > Question: doesn't the local repository we just created include all the
 > branches anyway?

Not as described in the wiki.  IIRC, there is currently no
straightforward way to mirror a whole bzr repository (except rsync
and/or tar), although the developers have made some noise about "doing
something".  When the wget+tar method gets straightened out, at least
that way will exist.

 > Didn't someone say that the repository allows working off-line?

Of course!

 > if so, it should include all the branches in the master repository, no?

Maybe.  It's not clear (eg, there's my discussion with Stefan about
where to put "sandbox" branches---they could go in the master
repository).

 >    Compared to CVS, these branches are lightweight --- it doesn't cost much
 >    to create them, as they're all sharing storage in the repository, and
 >    they can't bother anyone else. However, there is one "weighty"
 >    aspect: [etc, etc].

 > This is confusing and looks like a merge of 2 different narratives.

I'm not sure why you think that.  I've made some changes, but I'm not
real confident they address the confusion.

 > Is ``dedicated branch'' what is later described as ``feature
 > branches'' or something else?

Something else.  Rephrased to "branch dedicated to small changes".

 > If the source tree is ``weighty'', then why are the branches
 > ``lightweight''?

In Bazaar, the working tree and the branch metadata are basically
independent of each other; they can even reside on different hosts,
and branches can even exist without working trees.  Understanding this
is fundamental to designing efficient workflows for Bazaar.

However, in the context of a particular workflow, a collection of
trees, repositories, and branches will be associated with each other.

 > Why is it important that there will be no build products in the
 > tree? etc. etc.

That isn't obvious, even though I wrote "make bootstrap can take an
annoying amount of time"?  I've fiddled with it a bit, but I don't
know what to say.  If you still think it's confusing, I'll sleep on it
and try again in a day or so, or maybe Karl or a 3d party can do
something with it.

 >    Once you have completed the task, you'll want to send it
 >    upstream. You do this just as you would for a quick fix ...
 > 
 > What about branches in the master repository?  Unless I'm missing
 > something, the described workflows don't cover that.  What if I want
 > to have my branch available from the upstream?

What about them?  The workflows don't cover them, and won't, until
there's a policy permitting/regulating "sandbox" branches.  At this
point, only maintainers need to worry about them.  This is not a
document for maintainers (until Stefan, Yidong, or a release engineer
they appoint asks for it).

 > (Release branches will need that, right?)

Yes, but AIUI people who create release branches are not the target
audience of this document.

 > Finally, it looks like the TBDs near the end can be simply deleted
 > now, as what's before covers that turf already.

I thought about it, but there is too much history of bitching about
bzr performance (on bazaar@canonical and on the 'net in general, I'm
not referring to the discussion here) to ignore: people *will* want
"efficient" ways to use Bazaar.  I decided to recommend stacked
branches (sort of like a lightweight checkout, but all commits are
local until you explicitly merge), which are very efficient at
creation, and only accumulate history after creation.  The advantage
over checkouts is that someone who goes ahead and edits the working
tree can commit locally and "bzr send", as described elsewhere in the
document.

I did delete the "Merging packages" and "Emacs releases" sections, as
I think they're out of scope.  Since they didn't contain any useful
content, we're losing nothing until someone who needs that knowledge
asks for it.

Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: monnier@iro.umontreal.ca,
>     emacs-devel@gnu.org
> Date: Tue, 24 Nov 2009 10:33:50 +0900
> 
> Thanks for the review, Eli!

Thanks for writing that in the first place.

>  >    Compared to CVS, these branches are lightweight --- it doesn't cost much
>  >    to create them, as they're all sharing storage in the repository, and
>  >    they can't bother anyone else. However, there is one "weighty"
>  >    aspect: [etc, etc].
> 
>  > This is confusing and looks like a merge of 2 different narratives.
> 
> I'm not sure why you think that.

That was my way of trying to figure out what possible line of thinking
gave birth to that paragraph.  Forget it, I try explain the confusion
below in concrete terms.

>  > If the source tree is ``weighty'', then why are the branches
>  > ``lightweight''?
> 
> In Bazaar, the working tree and the branch metadata are basically
> independent of each other; they can even reside on different hosts,
> and branches can even exist without working trees.  Understanding this
> is fundamental to designing efficient workflows for Bazaar.

I'm not sure I understand this.  With the commands described on the
wiki, my understanding is that the history is in the `trunk' branch,
which is a mirror of (some) branches in the master repository, while
the source tree is in the development branches.  Is that true?

If this is true, then why does ``first bzr branch operation in a new
repository [...] take many minutes''?  It doesn't bring any source
files, only the history, right?  What brings the sources is the first
development branch you create, in our case with these commands:

    cd $DEVHOME/emacs
    bzr branch trunk/ quickfixes/

Right?

>  > Why is it important that there will be no build products in the
>  > tree? etc. etc.
> 
> That isn't obvious, even though I wrote "make bootstrap can take an
> annoying amount of time"?  I've fiddled with it a bit, but I don't
> know what to say.  If you still think it's confusing, I'll sleep on it
> and try again in a day or so, or maybe Karl or a 3d party can do
> something with it.

It's probably my confusion.  Let me take that paragraph apart and try
to show why it confuses the heck out of me.  I'm going to present a
narrative of my thoughts as I read the current text:

    Wiki: Compared to CVS, a Bazaar branch is lightweight -- it
    doesn't cost much to create one, as all branches in the repository
    are sharing storage

  Me: So far, so good...  Although it is not clear what storage is
  shared -- is it the sources that are common to all branches, the
  history, both?

    and they can't bother anyone else

  ??? what's this about? is it important? can it be deleted without
  sacrificing something important

    However, there is one "weighty" aspect: the source tree itself,
    which takes time to check out.

  okay, but when (at which time) does this weighty aspect rears its
  ugly head?  Is it at each "bzr branch" time?  Or does this happen
  only once?  If the latter, which one of the commands shown is the
  one that will cost me?

    Even more important, *there will be no build products in the
    tree.*

  "More important" than what?  Does this refer to the previous
  sentence or to the one before it?  And what's with "no build
  products in the tree" -- ain't I building Emacs in place?  Where
  will the products be, if not in the tree?

    make bootstrap takes an annoying amount of time.

  I knew that...

    That's why we recommend that for small changes you use and reuse a
    branch dedicated to such small changes.

  Does this "that's why" refer to the previous sentence about long
  bootstrap, or to everything else in this paragraph?

IOW, the logical thread of thought from one sentence to the next is
interrupted several times, and makes it hard to understand what the
text says and to discern facts from their explanation and the
recommendations.

I'm still not sure I understand the intent, but let me try to rewrite
this text assuming that I did understand:

  Bazaar allows all the branches in the repository to share storage,
  which makes the branches much more lightweight than CVS branches.
  However, it still takes time to checkout the source tree for each
  branch, and bootstrapping a new tree is annoyingly long.  That is
  why we recommend that for small changes you keep reusing the same
  ``quickfixes'' branch.  This way, once you bootstrapped the
  ``quickfixes'' branch once, the subsequent update, build, and commit
  steps of the update-edit-build-test-commit cycle will all be very
  fast, as long as you continue working in the same branch.

Note that I didn't put the "there will be no build products in the
tree" part anywhere, because my interpretation of the text (which is
probably incorrect or incomplete) didn't suggest any good place for
it.

>  > What about branches in the master repository?  Unless I'm missing
>  > something, the described workflows don't cover that.  What if I want
>  > to have my branch available from the upstream?
> 
> What about them?  The workflows don't cover them, and won't, until
> there's a policy permitting/regulating "sandbox" branches.  At this
> point, only maintainers need to worry about them.  This is not a
> document for maintainers (until Stefan, Yidong, or a release engineer
> they appoint asks for it).
> 
>  > (Release branches will need that, right?)
> 
> Yes, but AIUI people who create release branches are not the target
> audience of this document.

I thought the document targets maintainers as well.  Me, for example.

Thanks.

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > I'm not sure I understand this.  With the commands described on the
 > wiki, my understanding is that the history is in the `trunk' branch,
 > which is a mirror of (some) branches in the master repository, while
 > the source tree is in the development branches.  Is that true?

No.  The history of the project is not just the names, dates, and log
messages for versions.  It also includes the contents of the files that
make up each version, either as a copy of the file, or as a sequence
of diffs against some base version.  Since history is shared among
branches, the first branch is going to bring all the shared history,
plus a little bit of history that's specific to it.  This is
regardless of whether a source tree is checked out or not.

 >   Bazaar allows all the branches in the repository to share storage,
 >   which makes the branches much more lightweight than CVS branches.
 >   However, it still takes time to checkout the source tree for each
 >   branch, and bootstrapping a new tree is annoyingly long.  That is
 >   why we recommend that for small changes you keep reusing the same
 >   ``quickfixes'' branch.  This way, once you bootstrapped the
 >   ``quickfixes'' branch once, the subsequent update, build, and commit
 >   steps of the update-edit-build-test-commit cycle will all be very
 >   fast, as long as you continue working in the same branch.

That's better than what I had.

 > >  > (Release branches will need that, right?)
 > > 
 > > Yes, but AIUI people who create release branches are not the target
 > > audience of this document.
 > 
 > I thought the document targets maintainers as well.  Me, for example.

It targets maintainers to the extent that they're ordinary developers,
yes, but it seems likely to me that maintainers will be using
techniques that ordinary developers don't need to know about.  Like
creating release branches.  And they will need somewhat deeper
knowledge than the very superficial "do it this way at first and life
will start out good and only get better as you learn more" way this
document is written.

The way I think about this document, creating release branches is rare
enough and important enough that whoever does it can ask for help when
the time comes if they need it.  And I'm sure they'll get it,
immediately.

Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: monnier@iro.umontreal.ca,
>     emacs-devel@gnu.org
> Date: Tue, 24 Nov 2009 18:35:10 +0900
> 
> Eli Zaretskii writes:
> 
>  > I'm not sure I understand this.  With the commands described on the
>  > wiki, my understanding is that the history is in the `trunk' branch,
>  > which is a mirror of (some) branches in the master repository, while
>  > the source tree is in the development branches.  Is that true?
> 
> No.  The history of the project is not just the names, dates, and log
> messages for versions.  It also includes the contents of the files that
> make up each version, either as a copy of the file, or as a sequence
> of diffs against some base version.

Got it, thanks.

>  >   Bazaar allows all the branches in the repository to share storage,
>  >   which makes the branches much more lightweight than CVS branches.
>  >   However, it still takes time to checkout the source tree for each
>  >   branch, and bootstrapping a new tree is annoyingly long.  That is
>  >   why we recommend that for small changes you keep reusing the same
>  >   ``quickfixes'' branch.  This way, once you bootstrapped the
>  >   ``quickfixes'' branch once, the subsequent update, build, and commit
>  >   steps of the update-edit-build-test-commit cycle will all be very
>  >   fast, as long as you continue working in the same branch.
> 
> That's better than what I had.

So where did the part about no build products in the tree fit in here?
Which tree were you talking about?

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > So where did the part about no build products in the tree fit in here?
 > Which tree were you talking about?

The working tree checked out when you make a development branch
(quickfixes or feature branch) has no build products -> you have to
make bootstrap -> takes a long time for something that's supposed to
be a quick fix.

Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: monnier@iro.umontreal.ca,
>     emacs-devel@gnu.org
> Date: Tue, 24 Nov 2009 20:54:34 +0900
> 
> Eli Zaretskii writes:
> 
>  > So where did the part about no build products in the tree fit in here?
>  > Which tree were you talking about?
> 
> The working tree checked out when you make a development branch
> (quickfixes or feature branch) has no build products -> you have to
> make bootstrap -> takes a long time for something that's supposed to
> be a quick fix.

Funny I didn't get that before.  Thanks for explaining.

Re: bzr repository ready?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Funny I didn't get that before.  Thanks for explaining.

You're very welcome.  Dunno whether it's funny on your side or mine,
though.  These days, it's quite possible that I'm writing
"syntactically correct English" but intending "Japanese semantics". :-þ

By the way, I just added the following reference to BzrForEmacsDevs:

    http://doc.bazaar-vcs.org/migration/en/survival/bzr-for-git-users.html

(yeah, I wrote that, but it's pretty good :-) to the references.

While a lot of it only makes sense if you know git, there are two
glossary tables that give definitions of a lot of terms as used in git
and Bazaar, and I hope they might be useful to folks here.  Unfortunately
the corresponding document for CVS remains a stub. :-(

Re: bzr repository ready?

[Richard Stallman]

    The working tree checked out when you make a development branch
    (quickfixes or feature branch) has no build products -> you have to
    make bootstrap -> takes a long time for something that's supposed to
    be a quick fix.

Could we have scripts maintain a set of up-to-date .elc files somewhere?
Then people wanting to do something quick could download them instead
of bootstrapping.

Making the tarball with bzr data (was: bzr repository ready?)

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But the hard part is to integrate those 3 starting points with the
> "wget+untar" approach.

There is a very simple & safe method for creating a tarball that just
requires untarring at the other end.

First, create a bound branch of `trunk' on a shared repository [1]:

bzr init-repo emacs-repo
bzr checkout http://bzr.savannah.gnu.org/r/emacs/trunk

Now, the process of creating the tarball is:

cd emacs-repo/trunk
bzr update
cd ../..
tar the emacs-repo directory

The user just needs to download and untar to get a shared repository
containing `trunk' with read-only access to the GNU repository. A `bzr
update' is enough to get the latest changes and thus have a mirror of
the branch on the GNU repository.

If the user is an emacs hacker with write access rights, he does:

cd emacs-repo/trunk
bzr unbind
bzr bind sftp://bzr.savannah.gnu.org/r/emacs/trunk

And he is ready to start committing. [2]

If the user needs access to other branches, obtaining them with bazaar
just requires a few minutes, as only those revisions which are not
common with `trunk' will be downloaded.

If the user prefers other workflows, he has everything he needs, as he
can create branches from the mirror bound branch or unbind the mirror
branch, so this method is not restricted to the "bound work branch"
workflow.

Notes:

1. the `bzr init-repo emacs-repo' may require extra options for creating
a shared repository with the most efficient format on bazaar versions
previous to 2.0

2. something that hackers should do before the first commit is to
identify themselves with the `bzr whoami' command:

bzr whoami "Joe Hacker <joe.hacker@gnu.org>"

-- 
Óscar

Re: Making the tarball with bzr data (was: bzr repository ready?)

[Lennart Borgman]

On Tue, Nov 24, 2009 at 3:56 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> But the hard part is to integrate those 3 starting points with the
>> "wget+untar" approach.
>
> There is a very simple & safe method for creating a tarball that just
> requires untarring at the other end.
>
> First, create a bound branch of `trunk' on a shared repository [1]:
>
> bzr init-repo emacs-repo
> bzr checkout http://bzr.savannah.gnu.org/r/emacs/trunk
>
> Now, the process of creating the tarball is:
>
> cd emacs-repo/trunk
> bzr update
> cd ../..
> tar the emacs-repo directory
>
> The user just needs to download and untar to get a shared repository
> containing `trunk' with read-only access to the GNU repository. A `bzr
> update' is enough to get the latest changes and thus have a mirror of
> the branch on the GNU repository.
>
> If the user is an emacs hacker with write access rights, he does:
>
> cd emacs-repo/trunk
> bzr unbind
> bzr bind sftp://bzr.savannah.gnu.org/r/emacs/trunk
>
> And he is ready to start committing. [2]
>
> If the user needs access to other branches, obtaining them with bazaar
> just requires a few minutes, as only those revisions which are not
> common with `trunk' will be downloaded.
>
> If the user prefers other workflows, he has everything he needs, as he
> can create branches from the mirror bound branch or unbind the mirror
> branch, so this method is not restricted to the "bound work branch"
> workflow.


If I already have all the Emacs files locally (possibly with some
changes) how do I do to make this a bazaar thing? (This must be the
most common situation, or?)

Re: Making the tarball with bzr data

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

>> There is a very simple & safe method for creating a tarball that just
>> requires untarring at the other end.

[snip]

> If I already have all the Emacs files locally (possibly with some
> changes) how do I do to make this a bazaar thing? (This must be the
> most common situation, or?)

The most simple solution is to create a working bzr setup as explained
on the wiki and then copy the modified files you have on your CVS
checkout over the corresponding files on the work branch of the bzr
setup.

I'm talking here assuming that people will use the workflow documented
by Karl and Stephen.

BTW, one advantage of the workflow they recommend over the one I
documented and CVS (which are equivalent on this specific aspect) is
that, when you end your working session, you can commit your changes
locally with a comment about its state and what remains to be
done. Later, when you come back, read what you put on the last commit
and keep hacking. When the work is complete, you push to upstream (with
or without the history of your private commits).

Another advantage of their workflow is that you don't need to mix the
implementation of distint features on the same working source tree. You
can easily create your own personal local branches, one for each task
you are working on.

-- 
Óscar

Re: Making the tarball with bzr data

[Jason Earl]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Tue, Nov 24, 2009 at 3:56 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>> But the hard part is to integrate those 3 starting points with the
>>> "wget+untar" approach.
>>
>> There is a very simple & safe method for creating a tarball that just
>> requires untarring at the other end.
>>
>> First, create a bound branch of `trunk' on a shared repository [1]:
>>
>> bzr init-repo emacs-repo
>> bzr checkout http://bzr.savannah.gnu.org/r/emacs/trunk
>>
>> Now, the process of creating the tarball is:
>>
>> cd emacs-repo/trunk
>> bzr update
>> cd ../..
>> tar the emacs-repo directory
>>
>> The user just needs to download and untar to get a shared repository
>> containing `trunk' with read-only access to the GNU repository. A
>> `bzr update' is enough to get the latest changes and thus have a
>> mirror of the branch on the GNU repository.
>>
>> If the user is an emacs hacker with write access rights, he does:
>>
>> cd emacs-repo/trunk
>> bzr unbind
>> bzr bind sftp://bzr.savannah.gnu.org/r/emacs/trunk
>>
>> And he is ready to start committing. [2]
>>
>> If the user needs access to other branches, obtaining them with
>> bazaar just requires a few minutes, as only those revisions which are
>> not common with `trunk' will be downloaded.
>>
>> If the user prefers other workflows, he has everything he needs, as
>> he can create branches from the mirror bound branch or unbind the
>> mirror branch, so this method is not restricted to the "bound work
>> branch" workflow.
>
>
> If I already have all the Emacs files locally (possibly with some
> changes) how do I do to make this a bazaar thing? (This must be the
> most common situation, or?)

If you are primarily interested in tracking your own changes, then
simply doing a:

bzr init

in the root of the directory will get you started.  However, this makes
a brand new branch that is completely unrelated to the mainline Emacs
branch.  Merging your branch with the main Emacs branch would be far
more difficult than it needs to be, and so would getting new
improvements from the mainline Emacs branch.

So, that's probably not what you want to do.

What you probably want to do is to migrate the changes you have made to
Emacs into a new branch that can be used both to track changes made
upstream to Emacs and (hopefully) to allow you to develop new changes
that can be applied upstream.

The way to do that is to follow the instructions at:

http://www.emacswiki.org/emacs/BzrForEmacsDevs

to create a repository along with a "trunk" branch that tracks Emacs'
mainline development.  Then create a second branch (called, for example,
lennart).  Finally, use a tool like rsync to copy your changes into the
lennart branch.  You can then do:

bzr status

to see what files have changed and:

bzr diff

to generate a diff of what has changed.  Once you are satisfied that
your changes are the working tree for your shiny new branch.

bzr commit -m "Importing my changes into a new bzr branch"

will commit your changes to your local branch.

Hopefully this was helpful.

Jason

Re: bzr repository ready?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 23 Nov 2009 00:50:09 -0500
> Cc: emacs-devel@gnu.org
> 
> I think we should only consider setups that are close to what was done
> with CVS.  After that, people can read the Bzr docs to figure out what's
> best for them.

Please don't.  It would be a terrible waste of everyone's time to
figure out the various workflows entirely by trial and error.  There
are a few people here who have considerable knowledge and experience
using Bazaar; why not share some of that knowledge so that others get
a head start?

Btw, Bazaar docs are not of the best quality, to say the least.
Beyond simple tutorials (and this discussion already moved way past
what they describe), you'd better brace for a bumpy ride...

Re: bzr repository ready?

[Stefan Monnier]

>> I think we should only consider setups that are close to what was done
>> with CVS.  After that, people can read the Bzr docs to figure out what's
>> best for them.
> Please don't.  It would be a terrible waste of everyone's time to
> figure out the various workflows entirely by trial and error.  There
> are a few people here who have considerable knowledge and experience
> using Bazaar; why not share some of that knowledge so that others get
> a head start?

But anything that's not close to CVS will be non-specific to Emacs.
I.e. it's completely open-ended and there are as many different "ideal
setups" as there are readers of this list.


        Stefan

Re: bzr repository ready?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Mon, 23 Nov 2009 09:28:25 -0500
> 
> >> I think we should only consider setups that are close to what was done
> >> with CVS.  After that, people can read the Bzr docs to figure out what's
> >> best for them.
> > Please don't.  It would be a terrible waste of everyone's time to
> > figure out the various workflows entirely by trial and error.  There
> > are a few people here who have considerable knowledge and experience
> > using Bazaar; why not share some of that knowledge so that others get
> > a head start?
> 
> But anything that's not close to CVS will be non-specific to Emacs.
> I.e. it's completely open-ended and there are as many different "ideal
> setups" as there are readers of this list.

I was going to ask you to describe only the first 3 of those ``many
different setups'', but I see that you already did that.  Thanks.

Re: bzr repository ready?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Mon, 23 Nov 2009 06:11:35 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Right now, the only question that's come up that I think belongs in that
> >> document is "What should be the standard workflow for Emacs developers
> >> in Bazaar?"  That's a question we already had a draft answer for, and
> >> Stephen Turnbull has since improved it (I'm about to review it).
> >
> > Except that alternative workflows were mentioned here since then, and
> > it is no longer clear to me that the one described on the Wiki is the
> > best one.  Perhaps we should add a few more there.
> 
> There is no "best-one" workflow. It depends on what kind of work you do,
> what's your environment (i.e. connected/disconnected) and even on your
> personal preferences.

Note that I asked for several alternatives to begin with, because I
suspected that much.  I was told to go read the EmacsWiki page which
describes only one workflow.  Now you confirm my guess that more than
one workflow should be considered.

If others agree that ``there is no "best-one" workflow'', I would
suggest that several alternatives be described on the wiki, each one
with its advantages and disadvantages.  That should give each
developer enough information to make up her mind which ones to use, at
least initially.

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

>   $ diff -u cvs-all-tags bzr-all-tags | grep "^[+-]"
>     --- cvs-all-tags	2009-11-18 14:54:59.000000000 -0500
>     +++ bzr-all-tags	2009-11-18 15:13:28.000000000 -0500
>     -DAVELOVE
>     +EMACS_20_1
>     +EMACS_20_3
>     -FLYSPELL
>     -ILYA
>     -mh-e-8_1
>     -mh-e-8_2
>     -mh-e-doc-8_1
>     -mh-e-doc-8_2
>     -raeburn-tag-3-for-export
>     -small-dump-base
>     -URL

The raeburn-tag-3-for-export tag only exist in three files, two of which
are not *,v files.  The third file does no longer contain the revision
that this tag is referencing.  So for all practical purpose, this tag
does not exist.  The other missing tags (except for those that appear as
branches, see below) are due to bugs/limitations in cvsps and
inconsistent tagging (parsecvs can handle them much better).  I will
have to manually add them to the git and bzr repo.

>   The two tags that are present in Bazaar but not CVS are particularly
>   mystifying to me.  While 'EMACS_20_1' and 'EMACS_20_3' appear in
>   'bzr tags' in trunk, they do not appear in 'cvs log' output from the
>   top of the CVS tree.  I do not know where bzr got those tags from.
>   Since the CVS tag (e.g.) EMACS_20_2 exists, it is reasonable to
>   conclude that bzr is crazy and is getting _1 and _3 from somewhere.
>   But where?

Those are tags that I added manually.  I don't think that creates any
problems, other tags have been retroactively added in the past.

> * Check that all branches are present.  [?]
>
>   diff -u cvs-all-branches.out bzr-branches | grep "^[-+]"
>   --- cvs-all-branches.out	2009-11-18 16:52:50.000000000 -0500
>   +++ bzr-branches	2009-11-18 16:52:45.000000000 -0500
>   +Boehm-versions
>   +DAVELOVE
>   +FLYSPELL
>   +ILYA
>   +URL
>   -cedet-branch
>   -emacs-unicode

In my git repository, I created merge commits that merges the heads of
cedet-branch and emacs-unicode branch into the trunk and the
emacs-unicode-2 branch, resp.  Apparently bzr-fast-import does not
create a separate branch in such an event, but all the revisions are
present and referenced by the merge commit.  That is, if you removed the
cedet-branch and emacs-unicode heads from the git repo no commit would
become unreferenced.

>   "The Boehm-versions branch was a short-lived branch containing only
>    a gc directory.  It appears to be a mistaken checkin, the commit
>    that deleted the files has the log message 'Not committed to
>    branch, sorry.'."

Actually the Boehm-versions branch is a real branch in CVS, and I have
no idea why it doesn't appear in your list.  The files that are
referenced by this branch also appeared for a single revision on the
trunk, and were subsequently moved to the Boehm-GC branch.

>   He also said: "The Ilya_4_35 branch appears to be the result of
>   another git->bzr conversion bug.  It is an ordinary tag in git."  I
>   wonder if the same applies to ILYA now?  I could find out, but I'm
>   just going to send this mail now because I've been poking around in
>   CVS all day and I want to share some results!

Those extra branches are vendor branches.  They have very special
revision numbers (uneven number of digits, usually 1.1.1) that your
script miscategorized as non-branches.

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."

Re: bzr repository ready?

[Ken Raeburn]

On Nov 18, 2009, at 19:49, Andreas Schwab wrote:
> The raeburn-tag-3-for-export tag only exist in three files, two of  
> which
> are not *,v files.  The third file does no longer contain the revision
> that this tag is referencing.  So for all practical purpose, this tag
> does not exist.

Weird; I've no idea how that would've happened.  The tag would've  
related to tracking some work I was doing many years ago, so if it  
simplifies any of the transition work bookkeeping or sanity checking,  
feel free to delete it.

Ken

Re: bzr repository ready?

[Karl Fogel]

Thanks for the analysis, Andreas.  There appear to be no problems here.
You're right, I forgot about vendor branches (that part wasn't really a
script, I just of waved 'sed' and Emacs macros around in various ways,
but I forgot to account for vendor branch numbers).

-Karl

Andreas Schwab <schwab@linux-m68k.org> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>
>>   $ diff -u cvs-all-tags bzr-all-tags | grep "^[+-]"
>>     --- cvs-all-tags	2009-11-18 14:54:59.000000000 -0500
>>     +++ bzr-all-tags	2009-11-18 15:13:28.000000000 -0500
>>     -DAVELOVE
>>     +EMACS_20_1
>>     +EMACS_20_3
>>     -FLYSPELL
>>     -ILYA
>>     -mh-e-8_1
>>     -mh-e-8_2
>>     -mh-e-doc-8_1
>>     -mh-e-doc-8_2
>>     -raeburn-tag-3-for-export
>>     -small-dump-base
>>     -URL
>
> The raeburn-tag-3-for-export tag only exist in three files, two of which
> are not *,v files.  The third file does no longer contain the revision
> that this tag is referencing.  So for all practical purpose, this tag
> does not exist.  The other missing tags (except for those that appear as
> branches, see below) are due to bugs/limitations in cvsps and
> inconsistent tagging (parsecvs can handle them much better).  I will
> have to manually add them to the git and bzr repo.
>
>>   The two tags that are present in Bazaar but not CVS are particularly
>>   mystifying to me.  While 'EMACS_20_1' and 'EMACS_20_3' appear in
>>   'bzr tags' in trunk, they do not appear in 'cvs log' output from the
>>   top of the CVS tree.  I do not know where bzr got those tags from.
>>   Since the CVS tag (e.g.) EMACS_20_2 exists, it is reasonable to
>>   conclude that bzr is crazy and is getting _1 and _3 from somewhere.
>>   But where?
>
> Those are tags that I added manually.  I don't think that creates any
> problems, other tags have been retroactively added in the past.
>
>> * Check that all branches are present.  [?]
>>
>>   diff -u cvs-all-branches.out bzr-branches | grep "^[-+]"
>>   --- cvs-all-branches.out	2009-11-18 16:52:50.000000000 -0500
>>   +++ bzr-branches	2009-11-18 16:52:45.000000000 -0500
>>   +Boehm-versions
>>   +DAVELOVE
>>   +FLYSPELL
>>   +ILYA
>>   +URL
>>   -cedet-branch
>>   -emacs-unicode
>
> In my git repository, I created merge commits that merges the heads of
> cedet-branch and emacs-unicode branch into the trunk and the
> emacs-unicode-2 branch, resp.  Apparently bzr-fast-import does not
> create a separate branch in such an event, but all the revisions are
> present and referenced by the merge commit.  That is, if you removed the
> cedet-branch and emacs-unicode heads from the git repo no commit would
> become unreferenced.
>
>>   "The Boehm-versions branch was a short-lived branch containing only
>>    a gc directory.  It appears to be a mistaken checkin, the commit
>>    that deleted the files has the log message 'Not committed to
>>    branch, sorry.'."
>
> Actually the Boehm-versions branch is a real branch in CVS, and I have
> no idea why it doesn't appear in your list.  The files that are
> referenced by this branch also appeared for a single revision on the
> trunk, and were subsequently moved to the Boehm-GC branch.
>
>>   He also said: "The Ilya_4_35 branch appears to be the result of
>>   another git->bzr conversion bug.  It is an ordinary tag in git."  I
>>   wonder if the same applies to ILYA now?  I could find out, but I'm
>>   just going to send this mail now because I've been poking around in
>>   CVS all day and I want to share some results!
>
> Those extra branches are vendor branches.  They have very special
> revision numbers (uneven number of digits, usually 1.1.1) that your
> script miscategorized as non-branches.
>
> Andreas.

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Wed, 18 Nov 2009 17:29:35 -0500
> Cc: Andreas Schwab <schwab@linux-m68k.org>,
> 	Jason Earl <jearl@notengoamigos.org>,
> 	Ian Clatworthy <ian.clatworthy@canonical.com>
> 
> Okay, I've spent some time yesterday and today checking over the latest
> Bzr conversion, which I obtained thusly:
> 
>   $ scp -r kfogel@bzr.savannah.gnu.org:/srv/bzr/emacs emacs-bzr-repository
> 
> Below are the results.

Thanks.  My knowledge of bzr is close to zero, so please be gentle
with me ;-)

> * Spot-check a change.  [PASS]

What does it mean to "spot-check a change"?  Also, what are the
criteria for judging these "spot-checks", according to which you say
"PASS"?

>   These two changes in CVS...
> 
>      2006-01-12 05:20  jhd
> 
> 	* configure.in, nt/.cvsignore, nt/COPYING, nt/ChangeLog,
> 	nt/INSTALL, nt/README, nt/addpm.c, nt/addsection.c, nt/cmdproxy.c,
> 	nt/config.nt, nt/configure.bat, nt/ddeclient.c, nt/emacs.rc,
> 	nt/envadd.bat, nt/gmake.defs, nt/makefile.w32-in,
> 	nt/multi-install-info.bat, nt/nmake.defs, nt/paths.h, nt/preprep.c,
> 	nt/runemacs.c, nt/icons/emacs.ico, nt/icons/emacs21.ico,
> 	nt/inc/gettext.h, nt/inc/grp.h, nt/inc/sys/socket.h
> 	(XFT_JHD_BRANCH.[3,1,1,2,2,1,1,1,1,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2]):
> 
> 	Update from HEAD
> 
>   ...and...
> 
>     2006-01-12 05:24  jhd
> 
>     	* .cvsignore, AUTHORS, COPYING, ChangeLog, INSTALL.CVS,
> 	Makefile.in, config.bat, config.guess, config.sub, configure,
>         [...too many files to list here, really, hundreds of them...]
> 
>   ...match this merge commit in Bazaar on the XFT_JHD_BRANCH branch:
> 
>       [...]
>       ------------------------------------------------------------
>       revno: 60734 [merge]
>       committer: Jan Djärv <jan.h.d@swipnet.se>
>       timestamp: Thu 2006-01-12 10:25:48 +0000
>       message:
>         Update from HEAD
>       [...]
> 
>   ....which is 40000 lines long, so I'm not including it all here.

Would it be a good idea to show a few lines?  Or are you only
interested in the fact that the "Update from HEAD" log was caught?
How about the list of files -- did you verify that it is identical to
the original one?

>   These three changes in CVS...
> 
>     2002-10-29 04:45  lektu
>     	* nt/ChangeLog (1.74):
>     	Added "(tiny change)" marker.
>     
>     2002-10-29 04:41  lektu
>     	* lisp/ChangeLog (EMACS_21_1_RC.237):
>     	Add "(tiny change)" markers.
>     
>     2002-10-29 04:38  lektu
>     	* lisp/ChangeLog (1.4464):
>     	Added "(tiny change)" marker.
>     
>    ...match these *two* changes in Bazaar:
> 
>    (on the EMACS_21_1_RC branch):
>       ------------------------------------------------------------
>       revno: 40805
>       committer: Juanma Barranquero <lekktu@gmail.com>
>       timestamp: Tue 2002-10-29 09:41:08 +0000
>       message:
>         Add "(tiny change)" markers.
>       modified:
>         lisp/ChangeLog
>       
>    (on the trunk branch):
>       ------------------------------------------------------------
>       revno: 48050
>       committer: Juanma Barranquero <lekktu@gmail.com>
>       timestamp: Tue 2002-10-29 09:45:19 +0000
>       message:
>         Added "(tiny change)" marker.
>       modified:
>         lisp/ChangeLog
>         nt/ChangeLog

So what does it mean -- that the conversion tries to second-guess
filesets based on log entries?

Re: bzr repository ready?

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> * Spot-check a change.  [PASS]
>
> What does it mean to "spot-check a change"?  Also, what are the
> criteria for judging these "spot-checks", according to which you say
> "PASS"?

It means I randomly picked a change in CVS and confirmed that the same
change exists in Bazaar, with the same data and metadata.

> Would it be a good idea to show a few lines?  Or are you only
> interested in the fact that the "Update from HEAD" log was caught?
> How about the list of files -- did you verify that it is identical to
> the original one?

Nope.  In all the other spot-checks I did, I verified every file and
directory.  But in this one, it was too big to do manually, and I didn't
bother to script that it was the _exact_ same set of files.  Instead, I
just spot-checked the list of files too, from both directions (i.e.,
spot-check a few from the CVS side to make sure they were in Bzr, and a
few from the Bzr side to make sure they were in CVS).  Then I moved on
to other checks.  (After all, in theory, a full and complete automated
check of the conversion is equivalent to writing the converter in the
first place; anything less is simply deciding where to compromise :-) .)

>>   These three changes in CVS...
>> 
>>     2002-10-29 04:45  lektu
>>     	* nt/ChangeLog (1.74):
>>     	Added "(tiny change)" marker.
>>     
>>     2002-10-29 04:41  lektu
>>     	* lisp/ChangeLog (EMACS_21_1_RC.237):
>>     	Add "(tiny change)" markers.
>>     
>>     2002-10-29 04:38  lektu
>>     	* lisp/ChangeLog (1.4464):
>>     	Added "(tiny change)" marker.
>>     
>>    ...match these *two* changes in Bazaar:
>> 
>>    (on the EMACS_21_1_RC branch):
>>       ------------------------------------------------------------
>>       revno: 40805
>>       committer: Juanma Barranquero <lekktu@gmail.com>
>>       timestamp: Tue 2002-10-29 09:41:08 +0000
>>       message:
>>         Add "(tiny change)" markers.
>>       modified:
>>         lisp/ChangeLog
>>       
>>    (on the trunk branch):
>>       ------------------------------------------------------------
>>       revno: 48050
>>       committer: Juanma Barranquero <lekktu@gmail.com>
>>       timestamp: Tue 2002-10-29 09:45:19 +0000
>>       message:
>>         Added "(tiny change)" marker.
>>       modified:
>>         lisp/ChangeLog
>>         nt/ChangeLog
>
> So what does it mean -- that the conversion tries to second-guess
> filesets based on log entries?

Yes.  It's not "second-guessing", though, it's "first-guessing", because
CVS doesn't record atomic changesets, even though the people committing
in CVS intend atomic changesets (i.e., everything committed in a given
"cvs commit" command).  

For all version control systems FOO that support atomic changesets
(which is every system written since CVS, and many written before CVS),
all CVS->FOO converters must try to rederive the intended changesets
from CVS's almost-but-not-quite-good-enough metadata.  All the
converters use roughly the same method for doing so, but due to various
tweaks and options in the algorithm, they sometimes produce different
results.  Usually those differences are not important in practice.

-Karl

Re: bzr repository ready?

[Karl Fogel]

Karl Fogel <kfogel@red-bean.com> writes:
>> Sounds good to me (for what that's worth :).  Would you like me to
>> create a new test emacs-merges repository right now?
>
> If you don't mind, yes.  Doing another test conversion will help us
> establish that the conversion process is routinized enough to be
> reliable (I'll spot check the new emacs-merges repository, and hopefully
> so will others).)

Jason, I forgot to say: when you create the new (hopefully final)
emacs-merges test repository, can you do it with bzr 1.11, which is now
the latest?  (You probably would have anyway, I just wanted to mention
it in case you don't follow bzr releases closely.)

> Also, while we're doing that, we can be talking to the Savannah admins
> to make sure they're ready to host bzr.

https://savannah.gnu.org/support/index.php?106612 has started this
process.

-Karl

Re: bzr repository ready?

[Karl Fogel]

Jason Earl <jearl@notengoamigos.org> writes:
> The urls should look something like this:
> bzr://bzr.notengoamigos.org/emacs-merges-ce/master/

Jason, I've grabbed this and started spot-checking.  I'm also timing how
long it takes to get the data, and then how long it takes to do some log
operations locally (result: regular 'log' is fine, 'log -v' is slow.
But we knew that; work is under way on 'log -v').

I've started a more detailed switchover checklist.  I'm sure I've
forgotten things -- anyone should feel free to add items:

   http://www.red-bean.com/scriki/index.php/EmacsBzrSwitchover

-Karl

Re: bzr repository ready?

[Daniel Clemente]

>  http://www.red-bean.com/scriki/index.php/EmacsBzrSwitchover
> (Note: This could live somewhere else -- checked into the Emacs CVS repository, perhaps, or at emacswiki.org.

  I also think that this would be better in EmacsWiki; this way it will last longer, found by web searchers, linked from other web pages and more easily edited.

Re: bzr repository ready?

[Karl Fogel]

Daniel Clemente <dcl441-bugs@yahoo.com> writes:
>>  http://www.red-bean.com/scriki/index.php/EmacsBzrSwitchover
>> (Note: This could live somewhere else -- checked into the Emacs CVS
>> repository, perhaps, or at emacswiki.org. ...)
>
>   I also think that this would be better in EmacsWiki; this way it
>   will last longer, found by web searchers, linked from other web
>   pages and more easily edited.

Done:  http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover

-Karl

Re: bzr repository ready?

[Dan Nicolaescu]

Karl Fogel <kfogel@red-bean.com> writes:

  > Done:  http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover


Does the current bzr put the version info in the "bzr diff" headers?

Does "bzr log SUBDIR" work now?

Re: bzr repository ready?

[Karl Fogel]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>   > Done:  http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover
>
> Does the current bzr put the version info in the "bzr diff" headers?
> Does "bzr log SUBDIR" work now?

No, neither of those bugs is fixed yet -- respectively:

   https://bugs.edge.launchpad.net/bzr/+bug/130588
   https://bugs.edge.launchpad.net/bzr/+bug/97715

They're on the bzr developers' radar screen, and I think they will get
fixed eventually (I may work on #130588 myself, as soon as I'm done with
#306394, but #97715 is likely to be beyond my skills as a bzr dev for
some time).  Ian Clatworthy has just finished some log improvements
(https://lists.ubuntu.com/archives/bazaar/2009q1/052131.html) in
performance, and I will be asking him about the 'log SUBDIR' case again.

However, I thought we decided these didn't have to block the switchover?
It'd obviously be better if they were fixed, especially the latter; I'm
just not sure we have to wait.  After all, right now we're using a
system that doesn't even support renames :-).

Very much trying to avoid Error 33,
-Karl

Re: bzr repository ready?

[Dan Nicolaescu]

Karl Fogel <kfogel@red-bean.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > > Karl Fogel <kfogel@red-bean.com> writes:
  > >   > Done:  http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover
  > >
  > > Does the current bzr put the version info in the "bzr diff" headers?
  > > Does "bzr log SUBDIR" work now?
  > 
  > No, neither of those bugs is fixed yet -- respectively:
  > 
  >    https://bugs.edge.launchpad.net/bzr/+bug/130588
  >    https://bugs.edge.launchpad.net/bzr/+bug/97715
  > 
  > They're on the bzr developers' radar screen, and I think they will get
  > fixed eventually (I may work on #130588 myself, as soon as I'm done with
  > #306394, but #97715 is likely to be beyond my skills as a bzr dev for
  > some time).  Ian Clatworthy has just finished some log improvements
  > (https://lists.ubuntu.com/archives/bazaar/2009q1/052131.html) in
  > performance, and I will be asking him about the 'log SUBDIR' case again.
  > 
  > However, I thought we decided these didn't have to block the switchover?

No idea, but who said anything about blocking?

But it's a bit worrying that even bugs that should be very easy to fix
(like the diff bug) don't get addressed...

Re: bzr repository ready?

[Karl Fogel]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> No idea, but who said anything about blocking?

Sorry -- didn't mean to jump to conclusions.

> But it's a bit worrying that even bugs that should be very easy to fix
> (like the diff bug) don't get addressed...

Oh, that doesn't worry me so much.  Like any active project (say, Emacs,
*cough* *cough* :-) ) bzr gets more bug reports than it can process.
Triage is eternal.  There are many bugs that are "easy to fix", but
developer attention is still finite, and of course each fix needs a
regression test, which is frequently more work than the bugfix itself.

I have my eye on the diff bug.  The only reason I haven't started it is
that I want to a) finish this switchover work first, which is not
non-trivial, and b) finish #306394, which also affects Emacs in
particular.

The 'log SUBDIR' bug #97715 is deeper, and like #246891 ('log -v is
slow') it requires structural changes under the hood.  (I mention those
two together because 'log -v' would otherwise have been a workaround for
#97715.)  I'll do what I can to push those along.

-Karl

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> In the CVS tree, we have this change to lisp/cus-start.el:
>
>    ----------------------------
>    revision 1.50.2.39
>    date: 2008-06-12 01:34:43 -0400;  author: miles;  state: Exp; \
>    lines: +0 -45;  commitid: AfSvpHSiE9VuuC6t;
>    Merge from emacs--devo--0
>    
>    Revision: emacs@sv.gnu.org/emacs--lexbind--0--patch-88
>    ----------------------------
>
> That's on the 'lexbind' branch.  That change was part of a commit to
> many files.  I'm using a verbose cvs2cl.pl-generated ChangeLog (see
> http://www.red-bean.com/kfogel/emacs-bzr-switchover/cvs2cl-ChangeLog) to
> pick changes to spot-check, and it shows how the above is part of a
> larger change (note we're in UTC this time):
>
>    2008-06-12 05:34  miles
>
>         * lisp/cus-start.el, lisp/finder.el, lisp/window.el,
>         lisp/ChangeLog, lisp/bindings.el, lisp/ffap.el, lisp/menu-bar.el,
>         lisp/vc-cvs.el, lisp/longlines.el, lisp/vc.el, lisp/Makefile.in,
>         lisp/help-fns.el, lisp/help.el, lisp/replace.el,
>         doc/misc/gnus.texi, lisp/mail/sendmail.el, lisp/nxml/nxml-mode.el,
>         lisp/nxml/nxml-rap.el, lisp/nxml/nxml-util.el, doc/misc/ChangeLog,
>         src/data.c, src/window.c, src/buffer.c, src/window.h, src/coding.c,
>         src/ChangeLog, src/dispnew.c, src/xdisp.c, src/lisp.h,
>         lisp/gnus/ChangeLog, lisp/gnus/gnus-art.el, lisp/gnus/gnus-util.el,
>         lisp/gnus/nnir.el, lisp/gnus/mm-decode.el,
>         lisp/language/hanja-util.el, leim/quail/hangul.el, etc/NEWS
>         (lexbind.[39,19,36,224,57,29,50,33,32,68,48,57,54,65,13,32,8,5,5,\
>                   20,47,92,73,21,59,203,55,140,77,138,76,37,2,39,3,12,176]):
>
>         Merge from emacs--devo--0
>
>         Revision: emacs@sv.gnu.org/emacs--lexbind--0--patch-88
>
> For those new to cvs2cl.pl: the "(lexbind.[NUMBER,NUMBER,...])" at the
> end shows the branch name and then, for each listed file in order, the
> revision number of file's corresponding change on that branch.  You can
> see that the "39" matches the "1.50.2.39" in the 'cvs log' output, and
> 'cvs log' confirms that "1.50.0.2" is the branch number for "lexbind"
> (ignore the intermediate ".0", it's just a CVS idiosyncracy).  You can
> use 'cvs2cl.pl -b -r -t -S --utc' to generate this data yourself.
>
> So: given that this change exists as a discrete commit in CVS, I'd
> expect it to show up somewhere in the 'bzr log --long' output (see
> http://www.red-bean.com/kfogel/emacs-bzr-switchover/bzr-log.out).

This change is part of a merge commit that did not contribute anything
on its own (ie. there were no conflicts).  The changes it introduces are
identical in the merged branches, so there is no point in duplicating
the history that is already present in the merge parent.  In other
words, these two commands produce identical output:

git diff d38470869..d38470869^ -- lisp/cus-start.el
git diff d38470869^2..d38470869^^2 -- lisp/cus-start.el

The first gives the changes relative to the last merge commit on the
lexbind branch, the latter the changes between the last two merge
parents on the master branch.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@suse.de> writes:
> This change is part of a merge commit that did not contribute anything
> on its own (ie. there were no conflicts).  The changes it introduces are
> identical in the merged branches, so there is no point in duplicating
> the history that is already present in the merge parent.  In other
> words, these two commands produce identical output:
>
> git diff d38470869..d38470869^ -- lisp/cus-start.el
> git diff d38470869^2..d38470869^^2 -- lisp/cus-start.el
>
> The first gives the changes relative to the last merge commit on the
> lexbind branch, the latter the changes between the last two merge
> parents on the master branch.

Thanks.  So if I understand you correctly, we shouldn't worry about that
commit not showing up in the bzr history.  It was omitted (from git)
because the original changes themselves are already present via the
merge parent, and including the merge of that parent as a commit unto
itself wouldn't add any information.

I'll continue spot-checking with that in mind.

(Reading http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
to make sure I grok this completely... So in the merge of the lexbind
branch and the master branch, the lexbind branch is parent 1 and the
master branch is parent 2?)

-Karl

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> Thanks.  So if I understand you correctly, we shouldn't worry about that
> commit not showing up in the bzr history.  It was omitted (from git)
> because the original changes themselves are already present via the
> merge parent, and including the merge of that parent as a commit unto
> itself wouldn't add any information.

The change is not omitted, it is part of the merge commit.  It is just
not displayed when listing the changes in the file, since the merge
commit itself did not contribute anything new to it.

Technically, a merge commit is nothing more than a commit with more than
one parent.  It does not change anything on the state of the associated
tree when the other parents are omitted.

> (Reading http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
> to make sure I grok this completely... So in the merge of the lexbind
> branch and the master branch, the lexbind branch is parent 1 and the
> master branch is parent 2?)

The first parent is always the commit on the same branch, the other
parents (there can be more than two) are the commits from the merged
branches.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@suse.de> writes:
> The change is not omitted, it is part of the merge commit.  It is just
> not displayed when listing the changes in the file, since the merge
> commit itself did not contribute anything new to it.

Hmmm.  But I wasn't listing the changes on a particular file -- I was
just running 'bzr log --long' with no arguments, in my clone of the
emacs-merges-ce-master repository.

I tried it again with 'bzr log --long -v', and although it eventually
errored (see https://bugs.edge.launchpad.net/bzr/+bug/267670), it got
through to November 2002, well beyond the change in question from 2008:

   2008-06-12 05:34  miles
        [...]
        Merge from emacs--devo--0
        Revision: emacs@sv.gnu.org/emacs--lexbind--0--patch-88

Yet that 2008 change still didn't show up in the output.

You say it's "not displayed when listing the changes in the file, since
the merge commit itself did not contribute anything new to it" ("it"
presumably meaning the file).  But then is there any circumstance under
which it would be displayed?

I'm puzzled because, as far as CVS is concerned, there really was a
change here: on the 'lexbind' branch, lisp/cua-start.el received a
change in revision 1.50.2.39, and that change was a result of
"Merge from emacs--devo--0".  I'm not sure what the string
"Revision: emacs@sv.gnu.org/emacs--lexbind--0--patch-88" means in the
log message, but surely the fact that something happened to
lisp/cua-start.el at 05:34 on 2008-06-12, and that it was done by
'miles', should be showing up *somewhere* in the full log.  Yet there
is no record of this event at all.  Here are two consecutive changes
from the bzr log:

   ------------------------------------------------------------
   revno: 88620
   committer: Miles Bader <miles@gnu.org>
   timestamp: Thu 2008-06-12 05:49:27 +0000
   message:
     Remove RCS keywords
     
     Revision: emacs@sv.gnu.org/emacs--devo--0--patch-1232
   ------------------------------------------------------------
   revno: 88619
   committer: Glenn Morris <rgm@gnu.org>
   timestamp: Thu 2008-06-12 03:58:11 +0000
   message:
     *** empty log message ***
   ------------------------------------------------------------

This event would have happened between those, but it's not there.

Is my puzzlement justified, or am I missing something basic?

(I'm pressing on this partly because I need to be able to document some
of the differences from CVS; if merges don't show up in a log of the
whole project, that's something we should note.)

Thanks,
-Karl

Re: bzr repository ready?

[Stephen J. Turnbull]

Karl Fogel writes:
 > Andreas Schwab <schwab@suse.de> writes:
 > > The change is not omitted, it is part of the merge commit.  It is just
 > > not displayed when listing the changes in the file, since the merge
 > > commit itself did not contribute anything new to it.
 > 
 > Hmmm.  But I wasn't listing the changes on a particular file -- I was
 > just running 'bzr log --long' with no arguments, in my clone of the
 > emacs-merges-ce-master repository.

Traditionally :) bzr log had very different semantics from other
VCSes, and they were extremely proud of it.  It may or may not be a
bug.  So this is a question you should ask the bzr community.

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

> I'm puzzled because, as far as CVS is concerned, there really was a
> change here: on the 'lexbind' branch, lisp/cua-start.el received a
> change in revision 1.50.2.39, and that change was a result of
> "Merge from emacs--devo--0".

That's only because CVS has no way to represent merges.  The real change
happend on the master branch.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@suse.de> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>
>> I'm puzzled because, as far as CVS is concerned, there really was a
>> change here: on the 'lexbind' branch, lisp/cua-start.el received a
>> change in revision 1.50.2.39, and that change was a result of
>> "Merge from emacs--devo--0".
>
> That's only because CVS has no way to represent merges.  The real change
> happend on the master branch.

Okay, this puzzle has been solved: that change was a merge to the
'lexbind' branch, and indeed, I've found it in Bazaar in that branch.
Sorry for the noise.

Continuing my conversion spot-check, I've uploaded the results so far:

  http://www.red-bean.com/kfogel/emacs-bzr-switchover/sanity-checks.txt

(76 KB, a bit large for the mailing list maybe.)

Results so far: individual changes seem okay, but there are some
problems with branches and tags.

It looks like not all CVS tags are present.  Some of those might be
branch-point tags (and thus unnecessary in git or bzr)... but how the
conversion would recognize them as such I don't know.  And it's a lot of
tags missing: like, 224 of them.

As for branches: all the CVS branches appear to be present in Bazaar,
but there are still a few questions.

Jason, Andreas, and anyone else, if you could take a look in that file
and offer your thoughts, I'd appreciate it.  The strings to search for
are:

   "Spot-check a branch-sync change."

   "Check that all tags are present."

   "Check that all branches are present."

-Karl

Re: bzr repository ready?

[Andreas Schwab]

Karl Fogel <kfogel@red-bean.com> writes:

>    "Spot-check a branch-sync change."

This is another merge commit that your tool appears to mishandle.  When
checking out the cvs trees before and after the change I see no
difference to the corresponding git trees, except that the files that
were renamed in this merge appear under both names in the older CVS
checkout.  The latter may be a limitation of cvs when checking out a
date, or it could be due to an invalid direct manipulation of the cvs
history (manually adding a branch tag instead of going through cvs
add/rm).

>    "Check that all tags are present."

These tags are all present in the git tree.  May be a bug in the
git->bzr conversion.

>    "Check that all branches are present."

Likewise, the branches are all present in the git tree.

The emacs-unicode branch has been absorbed by the emacs-unicode-2 branch.

The Boehm-versions branch was a short-lived branch containing only a gc
directory.  It appears to be a mistaken checkin, the commit that deleted
the files has the log message "Not committed to branch, sorry.".

The Ilya_4_35 branch appears to be the result of another git->bzr
conversion bug.  It is an ordinary tag in git.

The master branch is what CVS calls the HEAD branch.

The master-UNNAMED-BRANCH contains changes belonging to revisions that
are unreachable from any branch tag.  The name was constructed by
parsecvs since such unreferenced commits cannot exist in git.  Actually,
this branch combines several such anonymous branches, but parsecvs could
not tell them apart.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr repository ready?

[Karl Fogel]

Andreas Schwab <schwab@suse.de> writes:
> Karl Fogel <kfogel@red-bean.com> writes:
>>    "Spot-check a branch-sync change."
>
> This is another merge commit that your tool appears to mishandle.  When
> checking out the cvs trees before and after the change I see no
> difference to the corresponding git trees, except that the files that
> were renamed in this merge appear under both names in the older CVS
> checkout.  The latter may be a limitation of cvs when checking out a
> date, or it could be due to an invalid direct manipulation of the cvs
> history (manually adding a branch tag instead of going through cvs
> add/rm).

Or more likely, direct manipulation of the files in the CVS repository
(i.e., renaming).

Thanks.  I probably could have done the same checks you just did, but I
have to admit that by that point I was ready to be doing something else
for a bit (these verifications take a lot of legwork :-) ).

>>    "Check that all tags are present."
>
> These tags are all present in the git tree.  May be a bug in the
> git->bzr conversion.

Yup.  We'll look into it.

>>    "Check that all branches are present."
>
> Likewise, the branches are all present in the git tree.

Okay, thanks.

> The master-UNNAMED-BRANCH contains changes belonging to revisions that
> are unreachable from any branch tag.  The name was constructed by
> parsecvs since such unreferenced commits cannot exist in git.  Actually,
> this branch combines several such anonymous branches, but parsecvs could
> not tell them apart.

I never would have thought of that.  Hunh.  Thanks.

-Karl

Re: bzr repository ready?

[Karl Fogel]

Jason,

The conversion seems to have a tag problem: there are a bunch of tags
that are in CVS, and that made it into Git, but that do not seem to be
present in the emacs-merges-ce Bazaar repository.

To see the list of missing tags, visit

  http://www.red-bean.com/kfogel/emacs-bzr-switchover/sanity-checks.txt

and search for "Check that all tags are present".  That section shows
how I generated the lists of tags, and how I compared them, and shows
the results of the comparison.

(I also want to look more closely at the "Spot-check a branch-sync change"
section in that file, but the tags thing is most important right now.)

Thoughts?

-Karl

Karl Fogel <kfogel@red-bean.com> writes:
> Andreas Schwab <schwab@suse.de> writes:
>> Karl Fogel <kfogel@red-bean.com> writes:
>>>    "Spot-check a branch-sync change."
>>
>> This is another merge commit that your tool appears to mishandle.  When
>> checking out the cvs trees before and after the change I see no
>> difference to the corresponding git trees, except that the files that
>> were renamed in this merge appear under both names in the older CVS
>> checkout.  The latter may be a limitation of cvs when checking out a
>> date, or it could be due to an invalid direct manipulation of the cvs
>> history (manually adding a branch tag instead of going through cvs
>> add/rm).
>
> Or more likely, direct manipulation of the files in the CVS repository
> (i.e., renaming).
>
> Thanks.  I probably could have done the same checks you just did, but I
> have to admit that by that point I was ready to be doing something else
> for a bit (these verifications take a lot of legwork :-) ).
>
>>>    "Check that all tags are present."
>>
>> These tags are all present in the git tree.  May be a bug in the
>> git->bzr conversion.
>
> Yup.  We'll look into it.
>
>>>    "Check that all branches are present."
>>
>> Likewise, the branches are all present in the git tree.
>
> Okay, thanks.
>
>> The master-UNNAMED-BRANCH contains changes belonging to revisions that
>> are unreachable from any branch tag.  The name was constructed by
>> parsecvs since such unreferenced commits cannot exist in git.  Actually,
>> this branch combines several such anonymous branches, but parsecvs could
>> not tell them apart.
>
> I never would have thought of that.  Hunh.  Thanks.
>
> -Karl

Re: bzr repository ready?

[Karl Fogel]

Jason Earl <jearl@notengoamigos.org> writes:
> I will take a look at this over the weekend, but I think that you are
> over-estimating how much I know about CVS, Bzr, Git, tags, Emacs, and
> Free Software in general.  Really my only qualifications are that I was
> able to get both bzr's cvsps-import and bzr-fast-import to work on the
> Emacs repository :).  Andreas did the heavy lifting when it came to
> making a suitable repository.  From his replies to you on the problems
> with the bzr repository it is very clear to me that you and he both know
> more about source code repositories than I even *want* to know.
>
> I probably need another smiley after that last sentence.
>
> On the other hand, I do like learning new things, and it is quite
> possible that all that is really needed is for someone to chase down a
> few bugs (something I am more than capable of doing).  So I am happy to
> help, ecstatic even.  I just don't want to get anyone's hopes up about a
> fast turnaround.

No worries, Jason -- just do whatever you have time to.  We're really
close now.

I'd say just insert some debugging prints into your importers: figure
out where they're discovering the tag information, stick the debugging
statements there, and see if that prints out (or doesn't print out) any
of the tags I listed as missing.  You have the big advantage of having
actually done the bzr imports, which Andreas and I haven't.

It may well be that there is an innocent explanation: perhaps those tags
didn't cover all the files, so bzr had no way (?) to represent them, as
tags in bzr are basically symbolic names for whole-tree revisions --
whereas in CVS a tag is attached to a specific revision in each file, so
only user convention enforces that a given tag appears in all files.

(That's something I could look at in the CVS records, but it would be
great if we could get inside the guts of the bzr converter and see it
actually making that decision.)

-Karl

Re: bzr repository ready?

[Stefan Monnier]

Any news on this front?

I think what we need now is a test Bzr repository in bzr.sv.gnu.org (so
we can test the various tools).

From what I can tell the Bzr service is not yet activated on Savannah
for the "emacs" project, but it seems that once it's done sftp access
will work fine, whereas bzr+ssh access suffers from an old version of
Bzr on bzr.sv (when I tried it complained about an unsupported protocol
and then reconnected with an older protocol).

Can someone contact the Savannah people to activate the Bzr service, and
then try and install Jason's latest converted repository
(http://bzr.notengoamigos.org/emacs-merges.tar.lzma).  Note that this
repository uses a recent format, so it proably won't be supported by
bzr.sv's old Bzr server, so at first only sftp access will work, so we
should try and get bzr.sv's Bzr upgraded.


        Stefan

Re: bzr repository ready?

[Stefan Monnier]

> If you want to use the 1.9 pack-based format then grabbing this
> repository now is the thing to do.  If you are interested in testing the
> new "brisbane-core" format then you'll have to give me a few hours to
> set one up.

I'm still using your incrementally-updated Bzr mirror (not sure which
format it uses) and I locally use the "old" pack-0.92 format, and
performance is acceptable.
So even if newer formats improve things, they are not crucial.
Furthermore, we can upgrade the repository's format at any time in the
future, so the initial format is not that important.

This of course doesn't mean that I do not appreciate your efforts to get
fast-import improved and to test the newer formats (and to a large
extent also provide the Bazaar folks with a large repository on which
performance problems can be seen&improved).  Just that I think the
serious problems on this front have been addressed already.


        Stefan

Re: bzr repository ready?

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Any news on this front?
>
> I think what we need now is a test Bzr repository in bzr.sv.gnu.org (so
> we can test the various tools).
>
> From what I can tell the Bzr service is not yet activated on Savannah
> for the "emacs" project, but it seems that once it's done sftp access
> will work fine, whereas bzr+ssh access suffers from an old version of
> Bzr on bzr.sv (when I tried it complained about an unsupported protocol
> and then reconnected with an older protocol).
>
> Can someone contact the Savannah people to activate the Bzr service, and
> then try and install Jason's latest converted repository
> (http://bzr.notengoamigos.org/emacs-merges.tar.lzma).  Note that this
> repository uses a recent format, so it proably won't be supported by
> bzr.sv's old Bzr server, so at first only sftp access will work, so we
> should try and get bzr.sv's Bzr upgraded.

How does this sound:

When Bazaar 1.14 comes out (it's in release-candidate stage now), Jason
does another repo conversion, and we ask Savannah to upgrade to the new
server.  We also get the latest version of Loggerhead installed (that
may come automatically with Bazaar, not sure).

1.14 will include the end-of-line conversion feature.  (It would be
great to be able to easily test Windows development!  Of course, Emacs
itself handles the different EOL styles, but still...)

On the one hand, I don't want infrastructure to bit-rot between when we
set it up and when the project actually starts using it for real
development.  On the other hand, we need to test.  Bazaar 1.14 seems
like a good compromise point.

-Karl

Re: bzr repository ready?

[Samuel Bronson]

On Tue, Apr 28, 2009 at 12:11 PM, Karl Fogel <karl.fogel@canonical.com> wrote:

> On the one hand, I don't want infrastructure to bit-rot between when we
> set it up and when the project actually starts using it for real
> development.  On the other hand, we need to test.  Bazaar 1.14 seems
> like a good compromise point.

So ... how are you going to get Savannah to upgrade bzr monthly, anyway?

(I haven't decided whether or not I'm kidding yet.)

Re: bzr repository ready?

[Karl Fogel]

Samuel Bronson <naesten@gmail.com> writes:
> On Tue, Apr 28, 2009 at 12:11 PM, Karl Fogel <karl.fogel@canonical.com> wrote:
>
>> On the one hand, I don't want infrastructure to bit-rot between when we
>> set it up and when the project actually starts using it for real
>> development.  On the other hand, we need to test.  Bazaar 1.14 seems
>> like a good compromise point.
>
> So ... how are you going to get Savannah to upgrade bzr monthly, anyway?
>
> (I haven't decided whether or not I'm kidding yet.)

I didn't expect we would ask for that.  On the other hand, if it's be
easy to make it a pushbutton process, then I don't see why not...

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <karl.fogel@canonical.com>
> Date: Tue, 28 Apr 2009 12:11:49 -0400
> Cc: Jason Earl <jearl@notengoamigos.org>, emacs-devel@gnu.org
> 
> 1.14 will include the end-of-line conversion feature.  (It would be
> great to be able to easily test Windows development!  Of course, Emacs
> itself handles the different EOL styles, but still...)

What exactly do we want to test in this regard?  Emacs source files
all have Unixy EOLs, at least for me (I do "cvs up -kb" all the time),
and I hope Bazaar will let me continue doing that.

Does Bazaar have an option of leaving text files with their original
EOL format?  If not, then Bazaar will have to be careful not to
convert EOLs in files that are kept in the repository with DOS EOLs --
these are the *.bat files and few of the Leim sources.

Re: bzr repository ready?

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
> What exactly do we want to test in this regard?  Emacs source files
> all have Unixy EOLs, at least for me (I do "cvs up -kb" all the time),
> and I hope Bazaar will let me continue doing that.
>
> Does Bazaar have an option of leaving text files with their original
> EOL format?  If not, then Bazaar will have to be careful not to
> convert EOLs in files that are kept in the repository with DOS EOLs --
> these are the *.bat files and few of the Leim sources.

Bazaar won't do anything differently without you asking it to.  See

http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line-conversion

Ideally, some people would test that it works to set up the conversion
so that one is editing CRLF files on Windows.

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <karl.fogel@canonical.com>
> Cc: Karl Fogel <karl.fogel@canonical.com>,  monnier@iro.umontreal.ca,  jearl@notengoamigos.org,  emacs-devel@gnu.org
> Date: Tue, 28 Apr 2009 14:11:52 -0400
> 
> Bazaar won't do anything differently without you asking it to.  See
> 
> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line-conversion

Thanks for the pointer.

> Ideally, some people would test that it works to set up the conversion
> so that one is editing CRLF files on Windows.

To do that, they will have to manually mark every file that should not
be EOL converted.  That job is not an easy one.

Re: bzr repository ready?

[Stefan Monnier]

> When Bazaar 1.14 comes out (it's in release-candidate stage now), Jason
> does another repo conversion, and we ask Savannah to upgrade to the new
> server.  We also get the latest version of Loggerhead installed (that
> may come automatically with Bazaar, not sure).

We can already start talking to the Savannah people to try and figure
out how an upgrade can take place, what needs to be done for it, who
needs help, ...
1.14 would indeed be a good choice because it significantly reduces the
amount of data transfered upon commit.

> 1.14 will include the end-of-line conversion feature.  (It would be
> great to be able to easily test Windows development!  Of course, Emacs
> itself handles the different EOL styles, but still...)

We don't want EOL conversion at all for our repository, so it's
irrelevant (except for the fact that Bzr has the feature (over CVS) that
it doesn't do any conversion, by default).


        Stefan

Re: bzr repository ready?

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> We can already start talking to the Savannah people to try and figure
> out how an upgrade can take place, what needs to be done for it, who
> needs help, ...
> 1.14 would indeed be a good choice because it significantly reduces the
> amount of data transfered upon commit.

I'll start this process when 1.14 is released.

> We don't want EOL conversion at all for our repository, so it's
> irrelevant (except for the fact that Bzr has the feature (over CVS) that
> it doesn't do any conversion, by default).

EOL conversion is something that each individual developer chooses (or
chooses to avoid) -- it wouldn't ever happen in the repository Savannah
hosts.

-Karl

Re: bzr repository ready?

[Stefan Monnier]

>> We can already start talking to the Savannah people to try and figure
>> out how an upgrade can take place, what needs to be done for it, who
>> needs help, ...
>> 1.14 would indeed be a good choice because it significantly reduces the
>> amount of data transfered upon commit.
> I'll start this process when 1.14 is released.

Thanks.

>> We don't want EOL conversion at all for our repository, so it's
>> irrelevant (except for the fact that Bzr has the feature (over CVS) that
>> it doesn't do any conversion, by default).

> EOL conversion is something that each individual developer chooses (or
> chooses to avoid) -- it wouldn't ever happen in the repository Savannah
> hosts.

If users use it at their end, they take the risk of seeing build
failures, or misbehaviors.


        Stefan

Re: bzr repository ready?

[Eli Zaretskii]

> From: Karl Fogel <karl.fogel@canonical.com>
> Date: Tue, 28 Apr 2009 15:31:38 -0400
> Cc: Karl Fogel <karl.fogel@canonical.com>, Jason Earl <jearl@notengoamigos.org>,
> 	emacs-devel@gnu.org
> 
> > We don't want EOL conversion at all for our repository, so it's
> > irrelevant (except for the fact that Bzr has the feature (over CVS) that
> > it doesn't do any conversion, by default).
> 
> EOL conversion is something that each individual developer chooses (or
> chooses to avoid) -- it wouldn't ever happen in the repository Savannah
> hosts.

But we should provide the default rule in the repository, IMO, and not
depend on the built-in defaults.

Re: bzr repository ready?

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> EOL conversion is something that each individual developer chooses (or
>> chooses to avoid) -- it wouldn't ever happen in the repository Savannah
>> hosts.
>
> But we should provide the default rule in the repository, IMO, and not
> depend on the built-in defaults.

Oy, I'm sorry I ever mentioned it...

We don't have to do anything: the default is already correct and will
stay that way.  It's something one changes in one's ~/.bazaar/ config
area; I don't see any way to specify it across the network, but it
doesn't matter as Emacs devs are unlikely to make the config change
anyway.  Let's please just pretend I never said anything about it :-).

Re: bzr repository ready?

[Karl Fogel]

Jason Earl <jearl@notengoamigos.org> writes:
> There is a small wrinkle to this continuing bzr saga.  I am currently
> getting an XML error when I try and create a 0.92-pack repository (the
> current default format).  It would appear that I can only create a
> repository in the shiny new brisbane-core format.
>
> I've already talked to Ian Clatworthy about this particular bug and it
> appears to be a bug in bzr itself and not in bzr fast-import.  I just
> recently finished filing a bug in launchpad.

I really think we should test in brisbane-core anyway, actually.  So
maybe this wrinkle has a silver lining?  (M-x mix-metaphor)

> I agree that Emacs doesn't need EOL conversion.  The primary advantage
> to requiring bzr 1.14 in my opinion is that the new brisbane-core format
> is faster pretty much across the board, and that the new repositories
> require significantly less space.  Another upside is that I am currently
> able to create brisbane-core repositories :).

Yes :-).

> The downside, of course, is that brisbane-core is so new that it is only
> available as a preview format in a release candidate of the newest
> stable bzr client.
>
> That seems like a pretty big downside.
>
> Of course, in a few months bzr 2.0 will be released and the
> brisbane-core format should be the default.

In our circumstances, it's okay to aim for the future.  Bzr keeps to its
release schedule pretty reliably, and we know we're not switching until
at least Q3 or Q4 anyway.  Requiring brisbane-core now will
inconvenience just a few people -- us testers.  By the time all devs
need it, it will be widely available.

So I really think it's okay.

Re: bzr repository ready?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 28 Apr 2009 14:30:27 -0400
> Cc: Jason Earl <jearl@notengoamigos.org>, emacs-devel@gnu.org
> 
> > 1.14 will include the end-of-line conversion feature.  (It would be
> > great to be able to easily test Windows development!  Of course, Emacs
> > itself handles the different EOL styles, but still...)
> 
> We don't want EOL conversion at all for our repository

Yes, I agree.

Re: bzr repository ready?

[Jason Rumney]

Karl Fogel wrote:
> 1.14 will include the end-of-line conversion feature.

Can it be disabled? Our experience with CVS is that it is a misfeature 
if it is forced on users.

Re: bzr repository ready?

[Samuel Bronson]

On Tue, Apr 28, 2009 at 7:47 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Karl Fogel wrote:
>>
>> 1.14 will include the end-of-line conversion feature.
>
> Can it be disabled? Our experience with CVS is that it is a misfeature if it
> is forced on users.

It comes that way out-of-the box, actually ;-). You don't have to do
anything to disable it.

Re: bzr repository ready?

[Karl Fogel]

Karl Fogel <karl.fogel@canonical.com> writes:
> How does this sound:
>
> When Bazaar 1.14 comes out (it's in release-candidate stage now), Jason
> does another repo conversion, and we ask Savannah to upgrade to the new
> server.  We also get the latest version of Loggerhead installed (that
> may come automatically with Bazaar, not sure).

I've filed https://savannah.gnu.org/task/index.php?9348 about installing
Bazaar 1.14.

Note that we already have Loggerhead (the Bazaar web interface)
installed, and I didn't file any ticket about upgrading it, because we
might already be running the latest version -- it's impossible to tell
what version of Loggerhead is running by looking at a Loggerhead page
(such as http://bzr.savannah.gnu.org/lh/gnash/files).  So I'm betting it
will Just Work with Bazaar 1.14; if it doesn't, upgrading it can be a
separate SR.

-Karl

Re: Moving to bzr?

[John Yates]

Jason Earl wrote:

>> I also think that it might be a good idea to wait for some of the
>> current repository format changes to land.  The new format in 1.9 is a
>> definite improvement, but I think that it would be wise to at least wait
>> until one of the rich-root variants becomes the default format.

Stefan Monnier replied:

>Based on the last discussion around rich-root becoming the default, I'd
>say "don't hold your breath".

Rich-root support is available today.  Any new bzr format will always be
rolled out accompanied by a rich-root variant.

That defaulting to rich-root may take bzr some time does that preclude
the emacs project from initializing its master repository as rich-root?
After that would not rich-rootiness simply propagate to new branches?

/john

Re: Moving to bzr?

[Stephen J. Turnbull]

John Yates writes:

 > That defaulting to rich-root may take bzr some time does that preclude
 > the emacs project from initializing its master repository as rich-root?
 > After that would not rich-rootiness simply propagate to new branches?

It's not rich-root itself that is most important, though rich-root is
indeed an important feature for the Emacs repository.  It's a
heuristic for "work on the repo format/other important aspects has
proceeded sufficiently far."  There are several changes in process
that promise to allow dramatically improved performance on very
frequent operations like "bzr log".  Some of those may need a new repo
format.

I will note that Python is currently creating a PEP to move the Python
repositories from Subversion to a DVCS.  The three candidates are bzr,
hg, and git.  Despite a strong prior bias toward bzr, the PEP
proponent's initial impression upon actually trying some of the
scenarios is a shocked "bzr is almost unusable, might kill off one-off
contributions from new contributors" [my paraphrase].  I expect that
will be moderated with experience in more scenarios, but if somebody
with a strong prior that bzr is a good way to go reacts in that
fashion, I think we have to worry that potential Emacs contributors
will do so, too.

Please do read the initial impressions section at the end of
http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64.  I'm
deliberately overstating the case ... maybe. :-(  The GNOME DVCS
survey also showed bzr as quite weak in comparison to the other two
leading candidates:
http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/

I do *not* intend to reopen a debate on which DVCS to use; that is
decided.  I do intend a caution about timing.  In terms of the tools
that people use daily, "fools rush in where angels fear to tread" and
"better the devil you know than the devil you don't" are proverbs we
should not take lightly.

Re: Moving to bzr?

[Richard M Stallman]

I have never tried any of these programs, and I make no assertion
about how they compare technically.  However, supposing there are
things about bzr which cause trouble, it is clear what we should do
about them.

Please report the problems (with test cases, when appropriate) to the
bzr developers.

Re: Moving to bzr?

[Giorgos Keramidas]

On Mon, 05 Jan 2009 06:20:31 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>> > I am updating bzr from their development branch and hence have the
>> > latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
>> > is running for >15 mins versus less than 3 mins for git. This is a
>                                    ^^^^^^^^^^^^^^^^^^^^^^^^
> "Less than 3 mins" is too slow, if what I've heard about git is
> correct.  Maybe the OP was testing that on Windows.

It probably is.  I just run 10 pulls from the remote Git repository with
less than 2 seconds of time for the pulls that are basically NOPs:

$ for count in $(jot 10 1 10) ; do \
    /usr/bin/time git fetch 2>&1 > /dev/null ; \
done | nl

     1          6.22 real         0.02 user         0.05 sys
     2          1.43 real         0.01 user         0.04 sys
     3          1.71 real         0.01 user         0.04 sys
     4          1.54 real         0.01 user         0.04 sys
     5          1.65 real         0.00 user         0.04 sys
     6          1.55 real         0.00 user         0.04 sys
     7          1.67 real         0.00 user         0.05 sys
     8          1.57 real         0.01 user         0.03 sys
     9          1.59 real         0.00 user         0.05 sys
    10          1.51 real         0.00 user         0.05 sys

That's more typical of the speed of Git for remote operations.

Re: Moving to bzr?

[Lennart Borgman]

On Mon, Jan 5, 2009 at 4:50 AM, Stephen J. Turnbull
<turnbull@sk.tsukuba.ac.jp> wrote:
> Eli Zaretskii writes:
>
>  > Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
>  > command to resync with the master repository?  Because if it is, it is
>  > slower than CVS by a large margin (but so is git's 3 min, so I assume
>  > "bzr pull" is not the equivalent of "cvs up -d").
>
> Are you testing on Windows?  git has historically had performance
> problems on Windows because its Unix-oriented optimizations are often
> pessimizations on Windows.

Does this mean bzr is unusable for w32 users (for a large project like Emacs)?

Re: Moving to bzr?

[Stephen J. Turnbull]

Lennart Borgman writes:

 > Does this mean bzr is unusable for w32 users (for a large project
 > like Emacs)?

I have no opinion on that.  You'll have to try it yourself.  I don't
use Windows, I'm just relaying or commenting on benchmark information
reported by reliable people.  Whether bzr is usable or not will depend
heavily on whether your usage requires slow operations very often.

I post because I have spent a lot of time evaluating DVCSes (for
XEmacs in autumn 2007, for ESR's book project -- currently stalled --
in December 2007, and now for the Python DVCS PEP (I'm responsible for
git information).  It seems a shame to have emacs-devel go around in
circles if I can contribute useful information.

I use git daily (with so few complaints that I've never bothered to
subscribe to the ML), also hg (which I don't like as much), and stay
in touch with their recent documentation.  They are high performance
and in my usage the UIs are very stable, so I don't follow the mailing
lists much.

I do participate in the Darcs and Bazaar mailing lists (reading them
on a daily basis), also GNU Arch (which is basically asleep).  While I
know that Stefan is occasionally visible on the Bazaar list, as is
Karl Fogel, they don't seem to be as well-informed (or maybe they just
don't have time to post about it here).

FWIW YMMV.

Re: Moving to bzr?

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> I do participate in the Darcs and Bazaar mailing lists (reading them
> on a daily basis), also GNU Arch (which is basically asleep).  While I
> know that Stefan is occasionally visible on the Bazaar list, as is
> Karl Fogel, they don't seem to be as well-informed (or maybe they just
> don't have time to post about it here).

No, I'm a bzr newbie (I very much want to see Emacs switch, though).

Re: Moving to bzr?

[dhruva]

Hello,

On Mon, Jan 5, 2009 at 3:18 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Mon, Jan 5, 2009 at 4:50 AM, Stephen J. Turnbull
> <turnbull@sk.tsukuba.ac.jp> wrote:
>> Eli Zaretskii writes:
>>
>>  > Is "bzr pull" the equivalent of "cvs up -d"?  That is, is that the
>>  > command to resync with the master repository?  Because if it is, it is
>>  > slower than CVS by a large margin (but so is git's 3 min, so I assume
>>  > "bzr pull" is not the equivalent of "cvs up -d").
>>
>> Are you testing on Windows?  git has historically had performance
>> problems on Windows because its Unix-oriented optimizations are often
>> pessimizations on Windows.
>
> Does this mean bzr is unusable for w32 users (for a large project like Emacs)?

I think Stephen was commenting on m$ port of git. I have been using
MSYS port of git for doing my official work and pull emacs. I have
never had any problems (and hence unsubscribed myself from their
mailing list). However, I remember one posting on #git about msys port
of git not able to support very large repositories (in gigabytes) and
emacs is far from that. The cygwin port does not have any such issues
I was told. So, between cygwin and msys port, you are all set to use a
working and usable git for serious work. One missing feature in msys
git is ability to run the git daemon server, cygwin supports that.

I am going to collect the output of 'timeit bzr.bat pull' which is
equivalent of 'time bzr pull' and post the results somewhere on the
web (need to figure out).

Also, I have a pretty high end laptop (IBM Thinkpad T61 with Intel Duo
(dual core) and 2GB RAM. It is not loaded as I do all my development
using a putty terminal connected to a GNU/Linux box. So, resource is
not an issue.

The sample output of 'timeit bzr.bat pull' looks like this:

Using saved parent location: http://bzr.notengoamigos.org/emacs/trunk/
Now on revision 95263.

Version Number:   Windows NT 5.1 (Build 2600)
Exit Time:        4:53 pm, Monday, January 5 2009
Elapsed Time:     0:04:59.984
Process Time:     0:00:00.046
System Calls:     6639636
Context Switches: 1925320
Page Faults:      299443
Bytes Read:       185970981
Bytes Written:    25746978
Bytes Other:      2649061

From:
95262 lektu     2009-01-05
      Fix typos.
Current:
95263 gm        2009-01-05
      Add 2009 to copyright years.

So, it was 1 change set! The memory usage was high too (I have not
logged it now). I can get perfmon logs for better analysis if
required.

Now, git (pulls and updates the local folder too) with all branches:

From:
commit 7b8942ecec62129282ab75ca8bc009618ec34124
Author: Glenn Morris <rgm@gnu.org>
Date:   Thu Dec 18 03:34:16 2008 +0000

    Fix reStructuredText funky capitalization.

To:
commit 5b9823795d0ec55a7a114f9fed93f773a8546908
Author: Martin Rudalics <rudalics@gmx.at>
Date:   Mon Jan 5 10:29:41 2009 +0000

    (x_set_frame_parameters): Make sure height (width) get
    applied when fullwidth (fullheight) is set.  (Bug#1522)

Version Number:   Windows NT 5.1 (Build 2600)
Exit Time:        5:04 pm, Monday, January 5 2009
Elapsed Time:     0:03:11.531
Process Time:     0:00:00.031
System Calls:     4480504
Context Switches: 1324154
Page Faults:      508523
Bytes Read:       565680562
Bytes Written:    102819912
Bytes Other:      1241955

I will start posting the details and hope it helps in deciding using
more scientific approach.

-dhruva

-- 
Contents reflect my personal views only!

Re: Moving to bzr?

[Nick Roberts]

 > I will start posting the details and hope it helps in deciding using
 > more scientific approach.

Please don't.  RMS has stated on several occasions that the choice of VCS for
Emacs development has been decided in favour of bzr i.e it's not up for
discussion.

If I want to find out about the performance of bzr I'll subscribe to the Bazaar
mailing list which would, perhaps, be a more appropriate place to report your
findings

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Moving to bzr?

[Lennart Borgman]

On Mon, Jan 5, 2009 at 1:14 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
>
>  > I will start posting the details and hope it helps in deciding using
>  > more scientific approach.
>
> Please don't.  RMS has stated on several occasions that the choice of VCS for
> Emacs development has been decided in favour of bzr i.e it's not up for
> discussion.

I think it is still interesting to know the performance for bzr on w32
for a project like Emacs.

Re: Moving to bzr?

[dhruva]

Hello,

On Mon, Jan 5, 2009 at 5:44 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
>
>  > I will start posting the details and hope it helps in deciding using
>  > more scientific approach.
>
> Please don't.  RMS has stated on several occasions that the choice of VCS for
> Emacs development has been decided in favour of bzr i.e it's not up for
> discussion.

Well, if it has been decided to use bzr, why are not creating a mirror
on savannah. The same way we have git, we could have a CVS mirror
setup on savannah. The server used for git/cvs/bzr will be same (from
same pool) and we can eliminate network related issues. Once the
performance of bzr is found favorable enough, flip the switch to make
bzr primary and cvs as a mirror of bzr repo. I am not trying start a
discussion on VCS afresh but looking forward to putting an end by
having some official dVCS. I would like to ideally use one dVCS for my
official work and private hacking. I prefer to use what Emacs uses in
the long run and develop some expertise in that area.

Regarding posting the performance results, I will post it on a website
and just send a link to it once on this list, do not worry about me
adding extra bytes to the mailing list :)

-dhruva

-- 
Contents reflect my personal views only!

Re: Moving to bzr?

[dhruva]

Hello,

On Tue, Jan 6, 2009 at 2:26 AM, Jason Earl <jearl@notengoamigos.org> wrote:
> In the interests of using a more scientific approach would it be
> possible to use the bzr protocol and switch to the copy of the
> repository with the new bzr format.
>
> This should be as simple as doing a:
>
> bzr pull bzr://bzr.notengoamigos.org/emacs-ce/trunk/ --remember
>
> in your test branch.

I tried and get the following error! I am using bzr from their development repo.

[dk]bzr pull bzr://bzr.notengoamigos.org/emacs-ce/trunk/ --remember
bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium
'<bzrlib.smart.medium.SmartTCPClientMedium object at 0x01273890>' has
reached its concurrent request limit. Be su

Traceback (most recent call last):
  File "c:\python\Lib\site-packages\bzrlib\commands.py", line 893, in
run_bzr_catch_errors
    return run_bzr(argv)
  File "c:\python\Lib\site-packages\bzrlib\commands.py", line 839, in run_bzr
    ret = run(*run_argv)
  File "c:\python\Lib\site-packages\bzrlib\commands.py", line 539, in
run_argv_aliases
    return self.run(**all_cmd_args)
  File "c:\python\Lib\site-packages\bzrlib\builtins.py", line 779, in run
    possible_transports=possible_transports)
  File "c:\python\Lib\site-packages\bzrlib\branch.py", line 123, in open
    possible_transports=possible_transports)
  File "c:\python\Lib\site-packages\bzrlib\bzrdir.py", line 778, in open
    return BzrDir.open_from_transport(t, _unsupported=_unsupported)
  File "c:\python\Lib\site-packages\bzrlib\bzrdir.py", line 811, in
open_from_transport
    return format.open(transport, _found=True)
  File "c:\python\Lib\site-packages\bzrlib\bzrdir.py", line 1756, in open
    return self._open(transport)
  File "c:\python\Lib\site-packages\bzrlib\bzrdir.py", line 2657, in _open
    return remote.RemoteBzrDir(transport)
  File "c:\python\Lib\site-packages\bzrlib\remote.py", line 93, in __init__
    response = self._call('BzrDir.open', path)
  File "c:\python\Lib\site-packages\bzrlib\remote.py", line 51, in _call
    return self._client.call(method, *args)
  File "c:\python\Lib\site-packages\bzrlib\smart\client.py", line 122, in call
    result, protocol = self.call_expecting_body(method, *args)
  File "c:\python\Lib\site-packages\bzrlib\smart\client.py", line 135,
in call_expecting_body
    method, args, expect_response_body=True)
  File "c:\python\Lib\site-packages\bzrlib\smart\client.py", line 80,
in _call_and_read_response
    readv_body=readv_body)
  File "c:\python\Lib\site-packages\bzrlib\smart\client.py", line 42,
in _send_request
    protocol_version)
  File "c:\python\Lib\site-packages\bzrlib\smart\client.py", line 105,
in _construct_protocol
    request = self._medium.get_request()
  File "c:\python\Lib\site-packages\bzrlib\smart\medium.py", line 672,
in get_request
    return SmartClientStreamMediumRequest(self)
  File "c:\python\Lib\site-packages\bzrlib\smart\medium.py", line 870,
in __init__
    raise errors.TooManyConcurrentRequests(self._medium)
TooManyConcurrentRequests: The medium
'<bzrlib.smart.medium.SmartTCPClientMedium object at 0x01273890>' has
reached its concurrent request limit. Be sure to finish_writing and f

bzr 1.11dev on python 2.5.2 (win32)
arguments: ['c:\\python\\Scripts\\bzr', 'pull',
'bzr://bzr.notengoamigos.org/emacs-ce/trunk/', '--remember']
encoding: 'cp1252', fsenc: 'mbcs', lang: None
plugins:
  bzrtools
c:\python\lib\site-packages\bzrlib\plugins\bzrtools [1.10]
  fastimport
c:\python\lib\site-packages\bzrlib\plugins\fastimport [unknown]
  gtk                  c:\python\lib\site-packages\bzrlib\plugins\gtk
[0.96.0.dev.1]
  launchpad
c:\python\lib\site-packages\bzrlib\plugins\launchpad [unknown]
  qbzr                 c:\python\lib\site-packages\bzrlib\plugins\qbzr
[0.9.6dev]
  stats
c:\python\lib\site-packages\bzrlib\plugins\stats [unknown]
  win32symlinks
c:\python\lib\site-packages\bzrlib\plugins\win32symlinks [0.92]
  x_bit
c:\python\lib\site-packages\bzrlib\plugins\x_bit [unknown]
*** Bazaar has encountered an internal error.
    Please report a bug at https://bugs.launchpad.net/bzr/+filebug
    including this traceback, and a description of what you
    were doing when the error occurred.

-dhruva

Re: Moving to bzr?

[dhruva]

Hello,

On Tue, Jan 6, 2009 at 8:59 AM, dhruva <dhruvakm@gmail.com> wrote:
> On Tue, Jan 6, 2009 at 2:26 AM, Jason Earl <jearl@notengoamigos.org> wrote:
>> In the interests of using a more scientific approach would it be
>> possible to use the bzr protocol and switch to the copy of the
>> repository with the new bzr format.
>>
>> This should be as simple as doing a:
>> bzr pull bzr://bzr.notengoamigos.org/emacs-ce/trunk/ --remember
>>
>> in your test branch.
>
> I tried and get the following error! I am using bzr from their development repo.
>
> [dk]bzr pull bzr://bzr.notengoamigos.org/emacs-ce/trunk/ --remember
> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium
> '<bzrlib.smart.medium.SmartTCPClientMedium object at 0x01273890>' has
> reached its concurrent request limit. Be su

I tried with:
bzr pull http://bzr.notengoamigos.org/emacs-ce/trunk/ --remember

And it works. It appears faster but am still using the 'http' and not
'bzr'. In git, that makes a big difference and it is suggested to use
'git' protocol. Is there something similar in bzr?
I feel 'bzr' expects the server to be running on port 4155. When I try
'telnet bzr.notengoamigos.org 4155', it fails to connect and hence I
feel the bzr server is down.

-dhruva

-- 
Contents reflect my personal views only!

Re: Moving to bzr?

[马旋（SuperMMX）]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, dhruva <dhruvakm@gmail.com> :

On Tue, 6 Jan 2009 11:37:08 +0530
dhruva <dhruvakm@gmail.com> wrote:

> I tried with:
> bzr pull http://bzr.notengoamigos.org/emacs-ce/trunk/ --remember
> 
> And it works. It appears faster but am still using the 'http' and not
> 'bzr'. In git, that makes a big difference and it is suggested to use
> 'git' protocol. Is there something similar in bzr?
> I feel 'bzr' expects the server to be running on port 4155. When I try
> 'telnet bzr.notengoamigos.org 4155', it fails to connect and hence I
> feel the bzr server is down.
> 
> -dhruva

I regularly pull updates from the same host with http about once a week,
and from my experience the speed is almost consistent, the time is about
1m - 1m30s.

Never tried bzr:// before.

- -- 
A. Because it makes the logic of the discussion difficult to follow.
Q. Why shoudn't I top post?
A. No.
Q Should I top post?

A: Because it destroys the flow of the conversation
Q: Why is it bad?
A: No, it's bad.
Q: Should I top post in replies to mailing lists? 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)

iEYEARECAAYFAkli+HYACgkQYjhzyV/TMxs2UACfQYUppevLidmgWRqVAmV+cL5z
E/oAniax6Z3E0eF/wRw79ysK72RjQMfC
=SW2M
-----END PGP SIGNATURE-----

Re: Moving to bzr?

[Daniel Clemente]

>
> I tried and get the following error! I am using bzr from their development repo.
>
> [dk]bzr pull bzr://bzr.notengoamigos.org/emacs-ce/trunk/ --remember
> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium
> '<bzrlib.smart.medium.SmartTCPClientMedium object at 0x01273890>' has
> reached its concurrent request limit. Be su
>
> Traceback (most recent call last):
> ...

  Could you report this in the Bazaar bug tracker?  Use: https://bugs.launchpad.net/bzr

  At least the error message could be improved so that it is nicer to the user.


-- Daniel

Re: Moving to bzr?

[Tassilo Horn]

dhruva <dhruvakm@gmail.com> writes:

Hi,

> I am updating bzr from their development branch and hence have the
> latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
> is running for >15 mins versus less than 3 mins for git.

Currently I don't follow the bzr repo, but use the git mirror.  But I
never got a pull that's longer than 20 seconds.  For example the pull I
did a minute ago fetching all changes between January first and now took
13 seconds.

I use the mirror at git://git.sv.gnu.org/emacs.git.

Bye,
Tassilo

Re: Moving to bzr?

[Miles Bader]

Tassilo Horn <tassilo@member.fsf.org> writes:
> Currently I don't follow the bzr repo, but use the git mirror.  But I
> never got a pull that's longer than 20 seconds.  For example the pull I
> did a minute ago fetching all changes between January first and now took
> 13 seconds.

It looks like the main problem is that the original author is running
windows.

-Miles

-- 
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Re: Moving to bzr?

[dhruva]

Hello,

On Fri, Jan 9, 2009 at 3:01 PM, Miles Bader <miles@gnu.org> wrote:
> Tassilo Horn <tassilo@member.fsf.org> writes:
>> Currently I don't follow the bzr repo, but use the git mirror.  But I
>> never got a pull that's longer than 20 seconds.  For example the pull I
>> did a minute ago fetching all changes between January first and now took
>> 13 seconds.
>
> It looks like the main problem is that the original author is running
> windows.
>

Git is very fast for me on M$ too. I am noticing some improvements in
the new bzr repo too. I had anti virus running on my system which was
a big cause for slow down. Every new file was getting scanned. If the
tool creates a lot of small files or open and close files too often,
this was triggering the on-access scanning. I figured out a hack to
disable it for the emacs repository folders and am seeing a noticeable
improvement. I am not collecting times for each invocation of bzr pull
and update. Once I have enough samples, I can post (on bzr list) the
average times. M$ has a nice tool called 'timeit' which is part of the
resource kit. This not only functions as a nix time command but also
stores the output in a DB. Repeated calls will append the information
to the DB file and you can query the average.

-dhruva

-- 
Contents reflect my personal views only!

Re: Moving to bzr?

[Eli Zaretskii]

Btw, does anyone know how does bzr handle the EOL problem?  I.e., does
it leave the original EOL format intact, or does it try to convert
Unix EOLs to DOS when pulling and the other way around when pushing?

Re: Moving to bzr?

[Juanma Barranquero]

On Fri, Jan 9, 2009 at 21:20, Eli Zaretskii <eliz@gnu.org> wrote:

> Btw, does anyone know how does bzr handle the EOL problem?

I think there's some discussion here:

  http://bazaar-vcs.org/LineEndings

    Juanma

Re: Moving to bzr?

[Eli Zaretskii]

> Date: Fri, 9 Jan 2009 21:26:52 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Fri, Jan 9, 2009 at 21:20, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Btw, does anyone know how does bzr handle the EOL problem?
> 
> I think there's some discussion here:
> 
>   http://bazaar-vcs.org/LineEndings

Thanks.

Re: Moving to bzr?

[Stefan Monnier]

> Btw, does anyone know how does bzr handle the EOL problem?  I.e., does
> it leave the original EOL format intact, or does it try to convert
> Unix EOLs to DOS when pulling and the other way around when pushing?

As of now, Bzr doesn't do any line-end manipulation.
There's some work in progress to be able to do line-end conversions,
which seems like it may appear within the next 6 months or so.
Last I heard it didn't seem like we need such a feature for
Emacs's repository.


        Stefan

Re: Moving to bzr?

[Jason Rumney]

Stefan Monnier wrote:
> As of now, Bzr doesn't do any line-end manipulation.
> There's some work in progress to be able to do line-end conversions,
> which seems like it may appear within the next 6 months or so.
> Last I heard it didn't seem like we need such a feature for
> Emacs's repository.
>   

For Emacs, we want to keep line ends as they are in the repository when 
checking out to other platforms, and we trust developers to use Emacs 
for their editing, not some other editor that screws with line-endings.

As long as whatever bzr developers finally implement allows us to stay 
with this, without having to mark files as binary and lose the ability 
to do text diffs, then it will be an improvement over cvs.

Re: Moving to bzr?

[Eli Zaretskii]

> X-Spam-Status: No, score=1.4 required=5.0 tests=DNS_FROM_RFC_POST 
> 	autolearn=no version=3.1.0
> Date: Sat, 10 Jan 2009 11:06:24 +0800
> From: Jason Rumney <jasonr@gnu.org>
> CC: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> Stefan Monnier wrote:
> > As of now, Bzr doesn't do any line-end manipulation.
> > There's some work in progress to be able to do line-end conversions,
> > which seems like it may appear within the next 6 months or so.
> > Last I heard it didn't seem like we need such a feature for
> > Emacs's repository.
> >   
> 
> For Emacs, we want to keep line ends as they are in the repository when 
> checking out to other platforms, and we trust developers to use Emacs 
> for their editing, not some other editor that screws with line-endings.
> 
> As long as whatever bzr developers finally implement allows us to stay 
> with this, without having to mark files as binary and lose the ability 
> to do text diffs, then it will be an improvement over cvs.

Agreed.

Re: Moving to bzr?

[Stefan Monnier]

>> > As of now, Bzr doesn't do any line-end manipulation.
>> > There's some work in progress to be able to do line-end conversions,
>> > which seems like it may appear within the next 6 months or so.
>> > Last I heard it didn't seem like we need such a feature for
>> > Emacs's repository.
>> 
>> For Emacs, we want to keep line ends as they are in the repository when 
>> checking out to other platforms, and we trust developers to use Emacs 
>> for their editing, not some other editor that screws with line-endings.
>> 
>> As long as whatever bzr developers finally implement allows us to stay 
>> with this, without having to mark files as binary and lose the ability 
>> to do text diffs, then it will be an improvement over cvs.

> Agreed.

Good.  So Bzr should be no worse than CVS in this respect.


        Stefan

Re: Moving to bzr?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 09 Jan 2009 21:27:30 -0500
> 
> Last I heard it didn't seem like we need such a feature for
> Emacs's repository.

Most of the veteran developers who work on non-Posix platforms indeed
don't need that, as they all have found through the years some way of
dealing with the possible snafus.  But newcomers might need something
more sophisticated than just "hands-off-my-EOLs" (which is a good
first approximation, btw, much better than the CVS defaults).

But my question was more to make sure the current bzr does not convert
EOLs at all (and it sounds like this is the case, which is good), or
at least has an easy way of forcing it into that behavior.

Re: Moving to bzr?

[Richard M Stallman]

    I am updating bzr from their development branch and hence have the
    latest and greatest. When I run a 'bzr pull' on Emacs repo daily, it
    is running for >15 mins versus less than 3 mins for git.

How about sending a _precise_ bug report to the bzr maintainers?

Re: Making the tarball with bzr data (was: bzr repository ready?)

[grischka]

> If I already have all the Emacs files locally (possibly with some
> changes) how do I do to make this a bazaar thing? (This must be the
> most common situation, or?)

In any case you need to get the official emacs bazaar repository
first.

If you have personal changes, create a branch.

Then, either:
1) copy your changed files over the ones in that branch
2) commit the resulting change as one single patch.

Or, if you have more than one change and want to have separate
commits for each, use a merge tool such as WinMerge:
1) compare your directory tree with the new development branch
2) For each feature:
    - copy the relevant chunks that affect the feature
    - commit with some message
    - repeat 2) until no differences are left.

Then you could publish your branch for others to test or improve.

HTH, grischka

Re: Making the tarball with bzr data (was: bzr repository ready?)

[Lennart Borgman]

On Mon, Nov 30, 2009 at 7:11 PM, grischka <grishka@gmx.de> wrote:
>> If I already have all the Emacs files locally (possibly with some
>> changes) how do I do to make this a bazaar thing? (This must be the
>> most common situation, or?)
>
> In any case you need to get the official emacs bazaar repository
> first.


Thanks grischka. I believe you, but this seems just crazy to me. What
are the reasons for this limitation? Are there any chances this can be
fixed?


> If you have personal changes, create a branch.
>
> Then, either:
> 1) copy your changed files over the ones in that branch
> 2) commit the resulting change as one single patch.
>
> Or, if you have more than one change and want to have separate
> commits for each, use a merge tool such as WinMerge:
> 1) compare your directory tree with the new development branch
> 2) For each feature:
>   - copy the relevant chunks that affect the feature
>   - commit with some message
>   - repeat 2) until no differences are left.
>
> Then you could publish your branch for others to test or improve.
>
> HTH, grischka
>
>

Re: Making the tarball with bzr data

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Mon, Nov 30, 2009 at 7:11 PM, grischka <grishka@gmx.de> wrote:
>>> If I already have all the Emacs files locally (possibly with some
>>> changes) how do I do to make this a bazaar thing? (This must be the
>>> most common situation, or?)
>>
>> In any case you need to get the official emacs bazaar repository
>> first.
>
>
> Thanks grischka. I believe you, but this seems just crazy to me.

Why?

> What are the reasons for this limitation?

How is that a limitation?

Let me guess. You are thinking on the CVS checkout you have with all
those patches for EmacsW32, right?

Well, a brute force solution is to setup your personal bzr Emacs branch
and then simply copy everything from your CVS checkout over the bzr
branch, or in Windows parlance, copy the contents of the folder
lennarts_CVS_checkout over lennarts_bzr_branch, overwriting
everythin. You can remove the CVS directories on the bzr branch, as they
would be useless once the switch at Savannah is complete.

It is a pity that you had no bzr at the time when EmacsW32 was started:
you could keep a clean history of the applied patches and publish the
branch on something like launchpad or from your webserver. At least, you
can start taking advantage from bzr since now: instead of having a
checkout with lots of patched files, once you copy them over the bzr
branch commit the changes:

bzr commit -m "All modifications I have so far"

Since this, for applying a new patch:

bzr commit -m "Fixes foo"

Speaking as somebody who is interested on your modifications, it would
be great if you could start from a pristine Emacs working tree and
commit one patch at a time, with a descriptive commit message, then
publish the branch :-)

I'm willing to help you (and anybody else) on the transition to bzr, but
please be more specific when describing the problems you are foreseeing.

-- 
Óscar

Re: Making the tarball with bzr data

[Lennart Borgman]

On Mon, Nov 30, 2009 at 8:35 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Mon, Nov 30, 2009 at 7:11 PM, grischka <grishka@gmx.de> wrote:
>>>> If I already have all the Emacs files locally (possibly with some
>>>> changes) how do I do to make this a bazaar thing? (This must be the
>>>> most common situation, or?)
>>>
>>> In any case you need to get the official emacs bazaar repository
>>> first.
>>
>>
>> Thanks grischka. I believe you, but this seems just crazy to me.
>
> Why?


Why do I have to copy the files? Why can't this setup be done with the
already existing files?


>> What are the reasons for this limitation?
>
> How is that a limitation?
>
> Let me guess. You are thinking on the CVS checkout you have with all
> those patches for EmacsW32, right?


Partly, but there is another problem. I thought I would get some help
with that since there are some helpful guys here who can teach me a
bit. Maybe I should tell you that problem...

I have put my little elisp library nXhtml at Launchpad so you can
download it with bzr. However a lot of people already have nXhtml
installed, but it was not checked out from Launchpad. It came from a
zip file or similar.

Now I believed that since bzr is a new modern system it would of
course have thought of that kind of situation. I am a bad manual
reader so I had probably just not understod how to do it... - it is of
course possible to update the files using only bzr. That was my
believe.

Maybe my believe is crazy. Maybe this should not be possible for some
reason. But I do not understand why.



> Well, a brute force solution is to setup your personal bzr Emacs branch
> and then simply copy everything from your CVS checkout over the bzr
> branch, or in Windows parlance, copy the contents of the folder
> lennarts_CVS_checkout over lennarts_bzr_branch, overwriting
> everythin. You can remove the CVS directories on the bzr branch, as they
> would be useless once the switch at Savannah is complete.


I am grateful for the explanations you and others have given for this.
I am just surprised that I have to copy the files. It certainly makes
the process slower in several ways. I have to do more. And there will
be more network traffic etc.


> It is a pity that you had no bzr at the time when EmacsW32 was started:
> you could keep a clean history of the applied patches and publish the
> branch on something like launchpad or from your webserver. At least, you
> can start taking advantage from bzr since now: instead of having a
> checkout with lots of patched files, once you copy them over the bzr
> branch commit the changes:
>
> bzr commit -m "All modifications I have so far"
>
> Since this, for applying a new patch:
>
> bzr commit -m "Fixes foo"


Thanks.


> Speaking as somebody who is interested on your modifications, it would
> be great if you could start from a pristine Emacs working tree and
> commit one patch at a time, with a descriptive commit message, then
> publish the branch :-)


I will think about it ;-)


> I'm willing to help you (and anybody else) on the transition to bzr, but
> please be more specific when describing the problems you are foreseeing.
>
> --
> Óscar

Re: Making the tarball with bzr data

[Stefan Monnier]

> Why do I have to copy the files?

Because the files are but a small part of the data that Bzr will want.

> Why can't this setup be done with the already existing files?

It can, but then you need to know which Bzr revision corresponds to the
files you have.

> Now I believed that since bzr is a new modern system it would of
> course have thought of that kind of situation. I am a bad manual
> reader so I had probably just not understod how to do it... - it is of
> course possible to update the files using only bzr. That was my
> believe.

That is the case if your zip file is a zip of the checkout Bzr tree
(probably a lightweight checkout so it isn't bloated by a complete copy
of the whole history), in which case it'll include a .bzr directory with
the necessary metadata.


        Stefan

Re: Making the tarball with bzr data

[Lennart Borgman]

On Mon, Nov 30, 2009 at 10:50 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Why do I have to copy the files?
>
> Because the files are but a small part of the data that Bzr will want.


Does not that depend on if I want/need the history data locally? If I
do not want to use it at all?


>> Why can't this setup be done with the already existing files?
>
> It can, but then you need to know which Bzr revision corresponds to the
> files you have.


In that case wouldn't it be possible to let bzr assume that the my
files are checked out from the current revision and then changed? (As
a separate command of course, for use in those circumstances where it
might make sense.)


>> Now I believed that since bzr is a new modern system it would of
>> course have thought of that kind of situation. I am a bad manual
>> reader so I had probably just not understod how to do it... - it is of
>> course possible to update the files using only bzr. That was my
>> believe.
>
> That is the case if your zip file is a zip of the checkout Bzr tree
> (probably a lightweight checkout so it isn't bloated by a complete copy
> of the whole history), in which case it'll include a .bzr directory with
> the necessary metadata.


Thanks.

Re: Making the tarball with bzr data

[Stefan Monnier]

>>> Why can't this setup be done with the already existing files?
>> It can, but then you need to know which Bzr revision corresponds to the
>> files you have.
> In that case wouldn't it be possible to let bzr assume that the my
> files are checked out from the current revision and then changed? (As
> a separate command of course, for use in those circumstances where it
> might make sense.)

Yes, it'd be possible.  I know of no VCS that allows you to do that
(including CVS, which has had moe yeqars than any other to provide such
a feature), so I think it's just much too low on the list of priorities.


        Stefan

Re: Making the tarball with bzr data

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Why do I have to copy the files? Why can't this setup be done with the
> already existing files?

You can do this, but it practice, it can cause a bit of confussion if
the files you already have correspond to a different revision than the
tip of the bzr branch you download. How would bzr know that those files
are not edited but instead belongs to a past revision?

> I have put my little elisp library nXhtml at Launchpad so you can
> download it with bzr. However a lot of people already have nXhtml
> installed, but it was not checked out from Launchpad. It came from a
> zip file or similar.
>
> Now I believed that since bzr is a new modern system it would of
> course have thought of that kind of situation. I am a bad manual
> reader so I had probably just not understod how to do it... - it is of
> course possible to update the files using only bzr. That was my
> believe.

First: if all your users had the very same version of your library, you
could distribute a tarballed .bzr/ directory with the necessary
metadata. Expecting this is unrealistic, though.

Second: the amount of traffic you save by re-using the source code on
the target machine is nil: when the user downloads the metadata, he gets
a compressed history of the source code. You could use a lightweight
checkout, and this would be a very short download indeed, but then the
user would be very constrained on their Bazaar usage, as almost all
interesting features of Bazaar are not usable when everything you have
at your disposal is a lightweight branch, apart from risking on the
problem mentioned above.

Third: if you are thinking about Bazaar as a system for distributing
your software, I think that pointing potential users to a bzr branch for
obtaining a copy of your library you are raising the entry barrier quite
a bit, unless your intended audience already knows Bazaar.

> Maybe my believe is crazy. Maybe this should not be possible for some
> reason. But I do not understand why.

It is possible. It is not worthwhile.

[snip]

-- 
Óscar

Re: Making the tarball with bzr data

[Stephen J. Turnbull]

Lennart Borgman writes:

 > Why do I have to copy the files? Why can't this setup be done with
 > the already existing files?

Basically, because Bazaar is not git.  In git, each object is
summarized with an SHA1 hash, and so you can verify that you have a
clean tree (with very high probability) without actually comparing the
file content.  Bazaar uses a different, history-dependent method to
track files, assigning a globally unique, *permanent* ID to each
file.  So in order to verify that you have the right files for the
version Bazaar believes to be there, Bazaar must diff every single
file.  If you think about it, you'll see any other behavior would make
Bazaar a very unreliable tool.

There no savings in network transport (Bazaar can't send only the
content of the version you check out), and no savings in local file IO
(in the best case, every file differs in the first byte so you check
them all out anyway), by reusing existing files.

N.B. Reuse of an existing tree is a theoretical possibility only in
git.  AFAIK it has not been implemented.

In Bazaar, I suspect you can do the following:

1.  bzr branch --treeless <Emacs trunk URL> tmp
2.  mv tmp/.bzr <existing Emacs tree top directory>

But this doesn't save any network transport (you still get all the
branch data), and not much time locally since bzr will need to diff
all the files to determine which ones to commit (it will believe they
have *all* changed based on timestamp).

Probably the best procedure is

1.  bzr branch <Emacs trunk URL> bzr-emacs
2.  rsync <options> old-emacs bzr-emacs

assuming that rsync has appropriate options to ensure that it won't
change the stat data (specifically size and timestamp, IIRC) that bzr
uses to check if a file has been changed.

 > I have put my little elisp library nXhtml at Launchpad so you can
 > download it with bzr. However a lot of people already have nXhtml
 > installed, but it was not checked out from Launchpad. It came from a
 > zip file or similar.
 > 
 > Now I believed that since bzr is a new modern system it would of
 > course have thought of that kind of situation.

No, because Bazaar is a new modern system it assumes you have a new
modern network connection with which to download the Bazaar metadata
and revision history reasonably quickly.  This is a one-time cost per
project you work on if you use the workflow recommended in
BzrForEmacsDevs.

 > Maybe my believe is crazy. Maybe this should not be possible for some
 > reason. But I do not understand why.

It is possible -- with git.  Emacs isn't using git.  And there are
things that Bazaar can do (eg, tracking renames efficiently) that git
cannot.  Unfortunately, tracking renames depends exactly on the
feature I described above (tracking files in bzr vs. tracking content
in git).  (In theory you could do both and get the best of both
worlds, but this hasn't been implemented in any VCS AFAIK.)

Re: Making the tarball with bzr data

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[snip]

> Probably the best procedure is
>
> 1.  bzr branch <Emacs trunk URL> bzr-emacs
> 2.  rsync <options> old-emacs bzr-emacs
>
> assuming that rsync has appropriate options to ensure that it won't
> change the stat data (specifically size and timestamp, IIRC) that bzr
> uses to check if a file has been changed.

There is nothing wrong with changing the timestamp of a file versioned
under Bazaar. It will be not flagged as modified on `bzr status'.

OTOH, a change on size indicates a change on content, and this will be
flagged as an edited file (modulo eol settings, which bazaar supports as
system-wide options).

Lennart: if you copy files on Windows from your CVS working tree to your
bzr working tree maybe you will see files flagged as modified due to
differences on eol.

[snip]

-- 
Óscar

Re: Making the tarball with bzr data

[Giorgos Keramidas]

On Mon, 30 Nov 2009 22:27:00 +0100, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Mon, Nov 30, 2009 at 8:35 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Well, a brute force solution is to setup your personal bzr Emacs branch
>> and then simply copy everything from your CVS checkout over the bzr
>> branch, or in Windows parlance, copy the contents of the folder
>> lennarts_CVS_checkout over lennarts_bzr_branch, overwriting
>> everythin. You can remove the CVS directories on the bzr branch, as they
>> would be useless once the switch at Savannah is complete.
>
> I am grateful for the explanations you and others have given for this.
> I am just surprised that I have to copy the files. It certainly makes
> the process slower in several ways. I have to do more. And there will
> be more network traffic etc.

Hi Lennard,

You will have to copy a bzr-based trunk, but this is something you will
only have to do the first time.  The cost of subsequent merges with the
Emacs upstream is significantly lower than the first copy.

Once you go through the initial 'pain' of having to branch from the
Emacs trunk, there are a few things to gain too:

  * You get to merge with the Emacs upstream branch as many times as you
    want.  All the merges are shown explicitly in the history of your
    local branch, so it is easier to reason about questions like "When
    was the last time my merge worked fine?" or to move between two
    different merge points, even if one of them is arbitrarily old.

  * Your w32 branch will be visible to others too, including its full
    merge history with the Emacs upstream.  You can publish your w32
    branch either on Launchpad or on your own web server, and other
    people can look at the changes, submit their own extra changes, and
    so on.

  * Once you commit your local changes to a bzr branch, it is much safer
    to experiment with *more* changes, since the already committed
    patches will not go away even if you wipe all the files in the
    working copy.  If you accidentally modify a file and break your
    local w32 copy in some annoying way, you can just check-out a fresh
    copy from bzr.