bzr help, please

bzr help, please

[Lars Magne Ingebrigtsen]

I was wondering whether it's possible to use the normal git work flow
with Emacs.

That is, commit stuff in the local repository first, and then push stuff
out to the Emacs repository later.

This is what I do in the git work flow:

$ git commit
$ git pull --rebase

<possibly resolve stuff and then commit in the merge>

$ git push

I guess that's what's called an "unbound branch" in bzr.  I tried
unbinding the bound branch I had, and now everything is very confused
and I don't dare use that any more, and will pull down a new repository.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: bzr help, please

[Paul Eggert]

On 06/30/11 15:26, Lars Magne Ingebrigtsen wrote:
> I tried
> unbinding the bound branch I had, and now everything is very confused
> and I don't dare use that any more, and will pull down a new repository.
> 

Here's what I do.  I keep a bound branch named "trunk" that I regularly sync
to the trunk, and I never change it except either (1) by "bzr up",
or (2) by "bzr merge ../someotherbranch && bzr commit -m 'whatever'".
If step (2) fails in the middle, I do a "bzr revert && bzr up &&
(cd ../someotherbranch && bzr merge ../trunk && bzr commit -m 'Merge from trunk.')"
and then go back and redo step (2).  All my real work is done in
../someotherbranch.

I am leaving out all the intermediate steps where I get real work done
(e.g., resolving merge conflicts), but I hope you get the idea.

Re: bzr help, please

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I guess that's what's called an "unbound branch" in bzr.  I tried
> unbinding the bound branch I had, and now everything is very confused
> and I don't dare use that any more, and will pull down a new repository.

Try bzr reconfigure --tree.

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 help, please

[Lars Magne Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> I am leaving out all the intermediate steps where I get real work done
> (e.g., resolving merge conflicts), but I hope you get the idea.

Yeah.  But I'm wondering whether it's easier to just go back to the
bound branch thingie.  :-)  I usually do rather small things on the
Emacs code, so the main annoyance is that it takes so long to check
stuff in.

But I think it's perhaps easier to solve that by having a separate Emacs
that I only use for vc mode.

Currently my work flow is

* change some stuff in some functions
* test it
* "bzr update"
* write the changelog really really fast so that there's no other
  commits getting in my way
* commit from vc-mode

The "write the ChangeLogs reall really fast" is, perhaps, the most
annoying bit.  Because if I get a ChangeLog conflict, that's five
minutes out the window while conflict-resoluting, bzr updating again,
checking in again...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: bzr help, please

[Stefan Monnier]

> This is what I do in the git work flow:

> $ git commit
> $ git pull --rebase

> <possibly resolve stuff and then commit in the merge>

> $ git push

With an unbound branch, you can do the same:

bzr commit
bzr rebase
bzr push

But AFAIK "bzr rebase" is still not included in Bazaar, instead you have
to install the "bzr-rewrite" plugin.  And last time I tried it, it
didn't seem 100% rock solid (probably a chick&egg problem for inclusion
in the core Bazaar).


        Stefan

Re: bzr help, please

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 01 Jul 2011 00:26:56 +0200
> 
> I was wondering whether it's possible to use the normal git work flow
> with Emacs.
> 
> That is, commit stuff in the local repository first, and then push stuff
> out to the Emacs repository later.

Why do you think you need this?  What's wrong with the 2 workflows
suggested on the Wiki?

Re: bzr help, please

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 01 Jul 2011 01:25:44 +0200
> 
> Yeah.  But I'm wondering whether it's easier to just go back to the
> bound branch thingie.  :-)  I usually do rather small things on the
> Emacs code, so the main annoyance is that it takes so long to check
> stuff in.

If you are annoyed by committing to the bound branch, then use the
separate local branch and then merge to the bound one and commit.
This is the second workflow suggested by the Wiki.

However, if you don't rebase your local branch, that will have an
undesirable consequence of having several unrelated commits appear as
one revision on mainline (unless one uses -n0 switch to "bzr log").

Why is the commit time annoying, btw?  You could continue working
during that time, can't you?

> * change some stuff in some functions
> * test it
> * "bzr update"
> * write the changelog really really fast so that there's no other
>   commits getting in my way
> * commit from vc-mode
> 
> The "write the ChangeLogs reall really fast" is, perhaps, the most
> annoying bit.  Because if I get a ChangeLog conflict, that's five
> minutes out the window while conflict-resoluting, bzr updating again,
> checking in again...

Install the changelog_merge plugin
(https://launchpad.net/bzr-changelog-merge), and you will never ever
have merge conflicts in ChangeLog files.  This will be included in the
next version 2.4 of bzr, but for now you will need to install it
separately.

Re: bzr help, please

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why is the commit time annoying, btw?  You could continue working
> during that time, can't you?

Emacs hangs while doing the checkin.  

> Install the changelog_merge plugin
> (https://launchpad.net/bzr-changelog-merge), and you will never ever
> have merge conflicts in ChangeLog files.  This will be included in the
> next version 2.4 of bzr, but for now you will need to install it
> separately.

Ah, thanks.  I'll install that plugin. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: bzr help, please

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 01 Jul 2011 12:14:41 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why is the commit time annoying, btw?  You could continue working
> > during that time, can't you?
> 
> Emacs hangs while doing the checkin.  

You can always do it from another Emacs, or from the shell prompt.

Re: bzr help, please

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> You can always do it from another Emacs, or from the shell prompt.

Yeah, like I said, I'll start having a separate Emacs up to do the
checkins. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: bzr help, please

[Juanma Barranquero]

On Fri, Jul 1, 2011 at 09:06, Eli Zaretskii <eliz@gnu.org> wrote:

> Install the changelog_merge plugin
> (https://launchpad.net/bzr-changelog-merge), and you will never ever
> have merge conflicts in ChangeLog files.  This will be included in the
> next version 2.4 of bzr, but for now you will need to install it
> separately.

2.4b4 does not include changelog_merge. There's a news_merge, but it
seems specific for bazaar's NEWS file.

Or do you mean that the funcionality will be included without
requiring a plugin?

    Juanma

Re: bzr help, please

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 1 Jul 2011 13:48:00 +0200
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> On Fri, Jul 1, 2011 at 09:06, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Install the changelog_merge plugin
> > (https://launchpad.net/bzr-changelog-merge), and you will never ever
> > have merge conflicts in ChangeLog files.  This will be included in the
> > next version 2.4 of bzr, but for now you will need to install it
> > separately.
> 
> 2.4b4 does not include changelog_merge.

Please report that to the bzr mailing list.  The URL above clearly
says

  INSTALLATION

  The changelog_merge plugin is included in bzr 2.4. If you have an
  earlier version...

And I clearly remember a message posted to the bzr mailing list saying
that it "landed".

Re: bzr help, please

[Stefan Monnier]

>> Why is the commit time annoying, btw?  You could continue working
>> during that time, can't you?
> Emacs hangs while doing the checkin.  

Indeed, VC is still very poor.  I miss pcl-cvs.


        Stefan

Re: bzr help, please

[Juanma Barranquero]

On Fri, Jul 1, 2011 at 16:07, Eli Zaretskii <eliz@gnu.org> wrote:

> Please report that to the bzr mailing list.

OK.

    Juanma

Re: bzr help, please

[Lars Magne Ingebrigtsen]

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

>> Emacs hangs while doing the checkin.  
>
> Indeed, VC is still very poor.  I miss pcl-cvs.

I think I've found an acceptable work flow for dealing with smaller bug
reports now.

First list the bugs, of course:

 8834 minor                [Drew Adams             ] 24.0.50; doc string of `I
 8858 minor                [Drew Adams             ] 24.0.50; duplicate defali
 8859 minor                [Drew Adams             ] 24.0.50; `display-current
 8860 minor                [Dani Moncayo           ] 24.0.50; Fontification in
 8885 minor                [nyc4bos@aol.com        ] 24.0.50; Temporary failur
 8891 minor                [Dave Abrahams          ] 23.3; save-buffer message
 8903 minor                [Drew Adams             ] 24.0.50; please index mor
 8904 minor                [Drew Adams             ] 24.0.50; describe `descri
 8905 minor                [Drew Adams             ] 24.0.50; "Bogus calling s
 8935 minor                [Drew Adams             ] 24.0.50; `substitute-comm

The ones that are totally unhandled show up in red, so I select one of
those with `RET', and read the report.

Then I fix the error, run "bzr update" in the shell, write the
ChangeLog, wait for the "bzr update" to finish, save the ChangeLog, `M-x
vc-dir RET', check in (wait wait wait wait), `F' the message, and then
`C done RET' to mark the bug as fixed and closed.

Using two Emacsen to check in was more work, since I had to find where I
was in the tree, and so on.

So if the check-in was asynchronous, as in the good old days, it'd be
mostly annoyance-free.  :-)
 
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: bzr help, please

[Lars Magne Ingebrigtsen]

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

>>> Why is the commit time annoying, btw?  You could continue working
>>> during that time, can't you?
>> Emacs hangs while doing the checkin.  
>
> Indeed, VC is still very poor.  I miss pcl-cvs.

Is there any reason why VC has to wait (synchronously) for the answer
from bzr when checking in?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: bzr help, please

[Stefan Monnier]

>>>> Why is the commit time annoying, btw?  You could continue working
>>>> during that time, can't you?
>>> Emacs hangs while doing the checkin.  
>> Indeed, VC is still very poor.  I miss pcl-cvs.
> Is there any reason why VC has to wait (synchronously) for the answer
> from bzr when checking in?

Of course not.  But that's what the code currently does (and since the
code does various things at the end of the command, fixing it requires
splitting this "rest" into a part that will still be done at the end of
the command (e.g. bury the buffer) and another that will be deferred to
the process sentinel).  And since that's in the generic code, this
requires some care so as not to break other backends.


        Stefan

Re: bzr help, please

[Stefan Monnier]

> Is there any reason why VC has to wait (synchronously) for the answer
> from bzr when checking in?

Oh, and of course Bzr itself has some problems with its locking
protocol which means that while "bzr commit" is in progress, "bzr
status" and pretty much all other interesting bzr commands in the same
checkout/branch will fail with a "can't get the lock" error.
Hopefully this will be fixed/improved at some point, but it means that
while VC can be improved you may not always be able to benefit from it.


        Stefan

Re: bzr help, please

[Lars Magne Ingebrigtsen]

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

> Of course not.  But that's what the code currently does (and since the
> code does various things at the end of the command, fixing it requires
> splitting this "rest" into a part that will still be done at the end of
> the command (e.g. bury the buffer) and another that will be deferred to
> the process sentinel).  And since that's in the generic code, this
> requires some care so as not to break other backends.

Yeah, splitting (complicated) code into sentinels can be rather tricky.

I hope that somebody gets sufficiently annoyed by this anti-productive
synchronous behaviour that they fix it, though.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/