Re: Making the tarball with bzr data (was: bzr repository ready?)

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.

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?

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?

[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?

[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?

[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?

[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?

[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

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?)