VC and bzr.

VC and bzr.

[Jan Djärv]

Hi.

Does anybody know if it is possible to make bzr commit from vc async?
Commit now takes at least 2-3 minutes, amd Emacs locks up during that time.

	Jan D.

Re: VC and bzr.

[Dan Nicolaescu]

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

> Hi.
>
> Does anybody know if it is possible to make bzr commit from vc async?

It's not possible as a simple option, VC would need changes to support that.

> Commit now takes at least 2-3 minutes, amd Emacs locks up during that time.

I start another emacs just for checking in.  [A lot of times it takes
a lot longer than 2-3 minutes :-(... maybe the switch to the mythical
smart bzr server (if it ever happens) will help ... ATM CVS looks like
a speed daemon]

Re: VC and bzr.

[Andreas Schwab]

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

> Does anybody know if it is possible to make bzr commit from vc async?
> Commit now takes at least 2-3 minutes, amd Emacs locks up during that time.

Use a branch instead of a checkout.  That's the only sane way to use a
DVCS.

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: VC and bzr.

[Jan Djärv]

Andreas Schwab skrev 2010-04-22 00.19:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> Does anybody know if it is possible to make bzr commit from vc async?
>> Commit now takes at least 2-3 minutes, amd Emacs locks up during that time.
>
> Use a branch instead of a checkout.  That's the only sane way to use a
> DVCS.
>

How will that help when committing to savannah?

	Jan D.

Re: VC and bzr.

[Andreas Schwab]

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

> Andreas Schwab skrev 2010-04-22 00.19:
>> Jan Djärv<jan.h.d@swipnet.se>  writes:
>>
>>> Does anybody know if it is possible to make bzr commit from vc async?
>>> Commit now takes at least 2-3 minutes, amd Emacs locks up during that time.
>>
>> Use a branch instead of a checkout.  That's the only sane way to use a
>> DVCS.
>>
>
> How will that help when committing to savannah?

Local commits are much faster.

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: VC and bzr.

[Jan D.]

Andreas Schwab wrote:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Andreas Schwab skrev 2010-04-22 00.19:
>>> Jan Djärv<jan.h.d@swipnet.se>  writes:
>>>
>>>> Does anybody know if it is possible to make bzr commit from vc async?
>>>> Commit now takes at least 2-3 minutes, amd Emacs locks up during that time.
>>> Use a branch instead of a checkout.  That's the only sane way to use a
>>> DVCS.
>>>
>> How will that help when committing to savannah?
> 
> Local commits are much faster.
> 

Yes, I know I have a few local branches.  But sometimes it has to go to 
savannah, or it will always be your private work.  That is what I'm 
talking about, not local branches.

	Jan D.

Re: VC and bzr.

[Andreas Schwab]

"Jan D." <jan.h.d@swipnet.se> writes:

> Yes, I know I have a few local branches.  But sometimes it has to go to
> savannah, or it will always be your private work.

So push it when and only when it's ready.

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: VC and bzr.

[Jan D.]

Andreas Schwab wrote:
> "Jan D." <jan.h.d@swipnet.se> writes:
> 
>> Yes, I know I have a few local branches.  But sometimes it has to go to
>> savannah, or it will always be your private work.
> 
> So push it when and only when it's ready.
> 

Push takes the same amount of time.  There is advantage to commit from 
VC, Changelogs and vl-logs are available in buffers for example.
It is kind of ironic to have a version control system for Emacs that 
can't be used from within Emacs.

	Jan D.

Re: VC and bzr.

[Jan D.]

Jan D. wrote:
> Andreas Schwab wrote:
>> "Jan D." <jan.h.d@swipnet.se> writes:
>>
>>> Yes, I know I have a few local branches.  But sometimes it has to go to
>>> savannah, or it will always be your private work.
>>
>> So push it when and only when it's ready.
>>
> 
> Push takes the same amount of time.  There is advantage to commit from 
> VC, Changelogs and vl-logs are available in buffers for example.
> It is kind of ironic to have a version control system for Emacs that 
> can't be used from within Emacs.
> 

Besides that, the wiki says this is a bad idea:

It might occur to you to save some effort by just doing bzr push 
directly to the upstream master from inside the TASKNAME branch:

       cd $DEVHOME/emacs/TASKNAME
       bzr push sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk/

Do not do this — it can cause history to be displayed in a strange way 
in the upstream master, any mirrors or branches of it, and your own 
branch later. Search for the word “hidden” in this mail for more details.

	Jan D.

Re: VC and bzr.

[Andreas Schwab]

"Jan D." <jan.h.d@swipnet.se> writes:

> It might occur to you to save some effort by just doing bzr push directly
> to the upstream master from inside the TASKNAME branch:
>
>       cd $DEVHOME/emacs/TASKNAME
>       bzr push sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk/

This only talks about topic branches. Of course you only push your
tracking 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: VC and bzr.

[Andreas Schwab]

"Jan D." <jan.h.d@swipnet.se> writes:

> Andreas Schwab wrote:
>> "Jan D." <jan.h.d@swipnet.se> writes:
>>
>>> Yes, I know I have a few local branches.  But sometimes it has to go to
>>> savannah, or it will always be your private work.
>>
>> So push it when and only when it's ready.
>>
>
> Push takes the same amount of time.

You only need to contact the server for the push, not for every commit.

> There is advantage to commit from VC, Changelogs and vl-logs are
> available in buffers for example.

Commits work the same.

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: VC and bzr.

[Óscar Fuentes]

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

>>>> Yes, I know I have a few local branches.  But sometimes it has to go to
>>>> savannah, or it will always be your private work.
>>>
>>> So push it when and only when it's ready.
>>>
>>
>> Push takes the same amount of time.
>
> You only need to contact the server for the push, not for every commit.

bzr != git

Remember that bzr considers the leftmost part of the DAG as a special
one. This is the reason why the Emacs repo is configured for rejecting
`bzr push' except for the simple case where the operation would build a
linear history on top of the previous one (i.e. a merge was
unnecessary.)

Re: VC and bzr.

[Andreas Schwab]

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

> Remember that bzr considers the leftmost part of the DAG as a special
> one.

As does git (see --first-parent).

> This is the reason why the Emacs repo is configured for rejecting
> `bzr push' except for the simple case where the operation would build a
> linear history on top of the previous one (i.e. a merge was
> unnecessary.)

Either merge or fast-forward.  That's exactly what you do with git as
well.

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: VC and bzr.

[Óscar Fuentes]

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

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Remember that bzr considers the leftmost part of the DAG as a special
>> one.
>
> As does git (see --first-parent).

That is just a cosmetic feature. bzr makes the distinction by default
and at a deeper level. On some common scenarios it can lead to an
apparent history rewriting, with the DAG arms flipping sides. The bzr
developers implemented a repo switch for rejecting that effect, and
Emacs is using it. Which is precisely why `bzr push' won't work on a
general basis.

>> This is the reason why the Emacs repo is configured for rejecting
>> `bzr push' except for the simple case where the operation would build a
>> linear history on top of the previous one (i.e. a merge was
>> unnecessary.)
>
> Either merge or fast-forward.  That's exactly what you do with git as
> well.

We are talking about `push' here. `bzr push' works only if a
fast-forward is possible. Same for `bzr pull'. From my reading of the
man pages, git doesn't merge on `push' either.

Re: VC and bzr.

[Andreas Schwab]

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

> We are talking about `push' here. `bzr push' works only if a
> fast-forward is possible. Same for `bzr pull'. From my reading of the
> man pages, git doesn't merge on `push' either.

So it works exactly like git.  You commit/merge locally and push when
ready.  That's one of the basic points of a DCVS.

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: VC and bzr.

[Óscar Fuentes]

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

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> We are talking about `push' here. `bzr push' works only if a
>> fast-forward is possible. Same for `bzr pull'. From my reading of the
>> man pages, git doesn't merge on `push' either.
>
> So it works exactly like git.  You commit/merge locally and push when
> ready.  That's one of the basic points of a DCVS.

I'm trying to convey this to you, but failing miserably at it:

* Merge point
  * Feature 1
  * Feature 2
  * Feature 3
* Previous stuff

Following your advice, that's how the history would look on bzr. People
using `log' without extra switches, or reading the emacs-diffs ml, will
see just

* Merge point
* Previous stuff

Now you would argue that those extra switches should be added via
aliases or wathever to `log' so they are always on, but then you will
face another problem with bzr: it is very difficult to rewrite history
(no good rebasing facilities, etc) so it is hard to rewrite your feature
branch into a nice series of commits for they looking good after
integrated upstream. Hence, people merge their feature branches as they
were created and this implies that the stuff shown by `bzr log -n0' is
not all that interesting.

That means that `bzr log -n0' would end as a mess of interesting and
trivial stuff, but `bzr log' would hide key developments.

Re: VC and bzr.

[Andreas Schwab]

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

> That means that `bzr log -n0' would end as a mess of interesting and
> trivial stuff, but `bzr log' would hide key developments.

Sorry, I don't get your point.  How is that different from "git log" vs.
"git log --first-parent"?

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: VC and bzr.

[Óscar Fuentes]

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

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> That means that `bzr log -n0' would end as a mess of interesting and
>> trivial stuff, but `bzr log' would hide key developments.
>
> Sorry, I don't get your point.  How is that different from "git log" vs.
> "git log --first-parent"?

Both `bzr log' and `git log --first-parent' are screwed by the workflow

merge from trunk into my feature branch
then, push to trunk

See http://thread.gmane.org/gmane.emacs.devel/120336/ for an instance of
what happens when somebody does that.

The problem is not serious on git because it doesn't make hard
distinctions among the parents of a merge point (unless you explicitly
request it). This is reason why `git log' shows all the DAG by
default. But bzr makes that distinction. On it relies bzr's capability
of assigning sequential numbers to commits, for instance.

Re: VC and bzr.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 22 Apr 2010 18:52:13 +0200
> 
> Both `bzr log' and `git log --first-parent' are screwed by the workflow
> 
> merge from trunk into my feature branch
> then, push to trunk

Unless you work on a feature for a very long time (months), there
should be no reasons for the "merge from trunk" part.

For example, I committed a few days ago 3-weeks worth of development
on a local branch, with no interim merges from mainline whatsoever.
When I merged back to the trunk, before committing to repository, I
had only 2 merge conflicts (one of them in ChangeLog, which cannot be
avoided, but is trivially fixed).

Perhaps we should modify the instructions on the wiki slightly, to
make the workflow slightly less annoying due to frequent slow commits
and at the same time avoid screwing up what "bzr log" shows on the
mainline.

Re: VC and bzr.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Both `bzr log' and `git log --first-parent' are screwed by the workflow
>> 
>> merge from trunk into my feature branch
>> then, push to trunk
>
> Unless you work on a feature for a very long time (months), there
> should be no reasons for the "merge from trunk" part.

Merging from trunk into a feature branch is not a serious problem (it
creates some noise on the history with the associated slowdown on bzr's
responsiveness, but that's all). But pushing to trunk after merging is a
serious problem as you (Eli) discovered:

http://thread.gmane.org/gmane.emacs.devel/120336/

See the output of

bzr log -r 99379 -n0

and notice how revisions that once resided on the leftmost part of the
DAG now appear on `trunk' as if they were merged by revision 99379.

[snip]

> Perhaps we should modify the instructions on the wiki slightly, to
> make the workflow slightly less annoying due to frequent slow commits
> and at the same time avoid screwing up what "bzr log" shows on the
> mainline.

The last part is fixed: the Emacs repo will reject operations that lead
to "bzr log" breakage.

The solution for the annoying slowness of commit operations is the smart
server, and if that doesn't reduce the required time to something
reasonable, the Bazaar people have the means for fixing the
problem.

Re: VC and bzr.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 22 Apr 2010 21:31:44 +0200
> 
> Merging from trunk into a feature branch is not a serious problem (it
> creates some noise on the history with the associated slowdown on bzr's
> responsiveness, but that's all). But pushing to trunk after merging is a
> serious problem as you (Eli) discovered:

This is a misunderstanding.  No one was suggesting such a workflow.

The suggestion was to commit locally more, and commit remotely less.
Which in practice means to work on a local branch, then merge back to
trunk when the changes are ready.  To avoid clutter in the history
log, I further suggested not to merge from mainline as long as one
works on a single feature in a local branch.  I find these merges
necessary only when I work for months on some very invasive feature.

> The solution for the annoying slowness of commit operations is the smart
> server

I'm not sure I will be alive, or around, long enough to see it happen.
It is ridiculous that it took me less time to develop bidirectional
display than it takes Savannah hackers to set up a server.  Perhaps
I'm too stupid to understand how this is possible.

Re: VC and bzr.

[Stefan Monnier]

> The solution for the annoying slowness of commit operations is the smart
> server,

Not fast enough to save us from async VC commit (which will also be
useful for CVS and Svn, although for CVS this is less pressing since
PCL-CVS already provides all-async functionality).

> and if that doesn't reduce the required time to something
> reasonable, the Bazaar people have the means for fixing the
> problem.

I don't know what that means or if it's true.


        Stefan

Re: VC and bzr.

[Óscar Fuentes]

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

>> The solution for the annoying slowness of commit operations is the smart
>> server,
>
> Not fast enough to save us from async VC commit (which will also be
> useful for CVS and Svn, although for CVS this is less pressing since
> PCL-CVS already provides all-async functionality).
>
>> and if that doesn't reduce the required time to something
>> reasonable, the Bazaar people have the means for fixing the
>> problem.
>
> I don't know what that means or if it's true.

The problem now is that bzr must operate on a remote filesystem and a
commit may require quite a bit of file I/O.

Once you have a friendly buddy on the other end, there is no reason for
a commit to a remote branch taking much more time than a local one,
being the setup of the ssh session the most expensive addition.

If Bazaar's server does not perform that way, it doesn't deserve the
"smart" tag. But at least the developers can improve it, contrary to
http/sftp.

Re: VC and bzr.

[Stefan Monnier]

>>> and if that doesn't reduce the required time to something
>>> reasonable, the Bazaar people have the means for fixing the
>>> problem.
>> I don't know what that means or if it's true.
> The problem now is that bzr must operate on a remote filesystem and a
> commit may require quite a bit of file I/O.
> Once you have a friendly buddy on the other end, there is no reason for
> a commit to a remote branch taking much more time than a local one,
> being the setup of the ssh session the most expensive addition.

Actually, that's not true.
For a "lightweight remote checkout", the commit (even over a smart
server) would be more difficult to make efficient than locally because
the commit requires a potentially large transfer of data because you
need to compare the new files (on one host) to the old files (on the
other host).
For other situations, the commit is really a commit+push, and the push
is equivalent to a "pull", just done the other way around.  And if
you've followed Bzr development, you'll know that Bzr is not that great
at doing pulls efficiently and it's unlikely to improve soon.


        Stefan

Re: VC and bzr.

[Óscar Fuentes]

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

>>>> and if that doesn't reduce the required time to something
>>>> reasonable, the Bazaar people have the means for fixing the
>>>> problem.
>>> I don't know what that means or if it's true.
>> The problem now is that bzr must operate on a remote filesystem and a
>> commit may require quite a bit of file I/O.
>> Once you have a friendly buddy on the other end, there is no reason for
>> a commit to a remote branch taking much more time than a local one,
>> being the setup of the ssh session the most expensive addition.
>
> Actually, that's not true.
> For a "lightweight remote checkout", the commit (even over a smart
> server) would be more difficult to make efficient than locally because
> the commit requires a potentially large transfer of data because you
> need to compare the new files (on one host) to the old files (on the
> other host).

I don't know why you care about lightweight remote checkouts, but
anyways it is not necessary to send the entire file over the wire. rsync
doesn't need to do that, why should bzr? Oh, wait... the bzr guys
doesn't particulary care about efficiency, do they?

> For other situations, the commit is really a commit+push, and the push
> is equivalent to a "pull", just done the other way around.  And if
> you've followed Bzr development, you'll know that Bzr is not that great
> at doing pulls efficiently and it's unlikely to improve soon.

Yes, they are happy enough with the current performance. Maybe if there
comes to be known among the crowd the fact about Emacs hackers not being
very pleased with their bzr experience, maybe the bzr guys would
reconsider their attitude and start caring about middle-sized projects
like Emacs.

It is a bit appalling to see how they boast about "bzr is now mature
enough to the point of being the choice for big projects like Emacs."

Oh, and I think that support for asyncrhonous commits on VC is good to
have, but with bzr sometimes taking *minutes* for a commit, special
situations must be considered, like the user editing and saving files
while the commit is on the way, or trying to commit something while the
previous one is not finished yet. It is not unlikely that some of those
scenarios may end with some breakage.

Re: VC and bzr.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 23 Apr 2010 04:18:09 +0200
> 
> Oh, and I think that support for asyncrhonous commits on VC is good to
> have, but with bzr sometimes taking *minutes* for a commit, special
> situations must be considered, like the user editing and saving files
> while the commit is on the way, or trying to commit something while the
> previous one is not finished yet. It is not unlikely that some of those
> scenarios may end with some breakage.

It is broken already.  As long as bzr is running, it locks the
.bzr/checkout/dirstate file, and visiting any file under bzr during
this time displays an error message because "bzr status" barfs due to
the locking.  This is for some reason more grave on MS-Windows,
probably because the way bzr opens files doesn't allow for sharing
with other programs.

And, btw, the speed of bzr operations doesn't matter much, because
even seconds would cause these problems with a significant
probability.

IOW, maybe bzr is good enough to use for Emacs development, but not
yet good enough to use it from within Emacs.  Someone should break the
news to Bazaar developers.

Until and unless this is fixed, I think we should stop using "bzr
status" for accessing VC-related information when we do file I/O.  We
should implement some other way of accessing that info, that doesn't
involve running bzr on each file op.  Or maybe we should access it
lazily (it's not that seeing the up-to-date revno in the mode line is
such a crucial feature), or somehow access it en masse, then cache it.

Re: VC and bzr.

[Stefan Monnier]

> Until and unless this is fixed, I think we should stop using "bzr
> status" for accessing VC-related information when we do file I/O.

There is code to parse the Bzr data "manually", so at least when opening
a file, we should be able to get the Bzr status info without
running Bzr.

> Or maybe we should access it lazily (it's not that seeing the
> up-to-date revno in the mode line is such a crucial feature), or
> somehow access it en masse, then cache it.

The revno is not important, indeed (maybe we should even stop
displaying it since it uses up precious modeline estate).

It's not the only info, tho:
- we also check&display whether or not the file is under Bzr control.
- we check&display whether it's locally edited or not.
- we run some hooks depending on the backend which may turn on smerge-mode

Note that with the proliferation of backends there is some pressure to
reduce the amount of work done per-backend when visiting a file.
So maybe we should completely stop checking the VC state when visiting
a file, and only do it when the user invokes VC.  This will mean that
the VC status won't appear in the modeline any more (or we could set it
up "in the background") and that we can't easily enable smerge-mode when
there are conflicts (unless we scan each and every file for diff3
markers).


        Stefan

Re: VC and bzr.

[Óscar Fuentes]

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

[snip]

> The revno is not important, indeed (maybe we should even stop
> displaying it since it uses up precious modeline estate).
>
> It's not the only info, tho:
> - we also check&display whether or not the file is under Bzr control.
> - we check&display whether it's locally edited or not.
> - we run some hooks depending on the backend which may turn on smerge-mode
>
> Note that with the proliferation of backends there is some pressure to
> reduce the amount of work done per-backend when visiting a file.
> So maybe we should completely stop checking the VC state when visiting
> a file, and only do it when the user invokes VC.  This will mean that
> the VC status won't appear in the modeline any more (or we could set it
> up "in the background") and that we can't easily enable smerge-mode when
> there are conflicts (unless we scan each and every file for diff3
> markers).

I find the status indicator (the `:' or `-' chars that flags a file as
modified on disk or not) very helpful. While working with git trees,
having the branch name on the modeline is extremely helpful.

IMHO, it is wrong to cut down global VC features just because some
backend is slow.

Re: VC and bzr.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 23 Apr 2010 16:43:29 +0200
> 
> I find the status indicator (the `:' or `-' chars that flags a file as
> modified on disk or not) very helpful.

They don't get updated unless you revert the buffer, or do all your VC
ops from within Emacs.  So they lie to me quite a bit.

> IMHO, it is wrong to cut down global VC features just because some
> backend is slow.

This has nothing to do with slowness, see my message for the details.

Re: VC and bzr.

[Davis Herring]

>> I find the status indicator (the `:' or `-' chars that flags a file as
>> modified on disk or not) very helpful.
>
> They don't get updated unless you revert the buffer, or do all your VC
> ops from within Emacs.  So they lie to me quite a bit.

In Emacs 21 (and 22, I think), C-x v v on a file that had been, say,
committed outside of Emacs since you saved it would update that status
(e.g., ":1.4" -> "-1.5").  That stopped working in 23 (not that it was
ever a documented feature, I suppose); perhaps we should put it back, or
add a command `vc-refresh' or so.  Of course, `revert-buffer' does work,
but ideally this "new" feature would not lose the undo history and reapply
the major mode and so on.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: VC and bzr.

[Dan Nicolaescu]

"Davis Herring" <herring@lanl.gov> writes:

>>> I find the status indicator (the `:' or `-' chars that flags a file as
>>> modified on disk or not) very helpful.
>>
>> They don't get updated unless you revert the buffer, or do all your VC
>> ops from within Emacs.  So they lie to me quite a bit.
>
> In Emacs 21 (and 22, I think), C-x v v on a file that had been, say,
> committed outside of Emacs since you saved it would update that status
> (e.g., ":1.4" -> "-1.5").  That stopped working in 23 (not that it was
> ever a documented feature, I suppose); perhaps we should put it back, or
> add a command `vc-refresh' or so.  Of course, `revert-buffer' does work,
> but ideally this "new" feature would not lose the undo history and reapply
> the major mode and so on.

Can you please file a bug with a step by step description of the problem?

Re: VC and bzr.

[Davis Herring]

>> (not that it was ever a documented feature, I suppose); perhaps we
should put it back, or
[...]
> Can you please file a bug with a step by step description of the problem?

Is it really a bug?  I thought it was just an accidental feature of C-x v
v that no longer existed.  The docstring doesn't mention the case where
Emacs' idea of the file's status is out of date.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: VC and bzr.

[Dan Nicolaescu]

"Davis Herring" <herring@lanl.gov> writes:

>>> (not that it was ever a documented feature, I suppose); perhaps we
> should put it back, or
> [...]
>> Can you please file a bug with a step by step description of the problem?
>
> Is it really a bug? 

It's hard to say without being able to try it...

>  I thought it was just an accidental feature of C-x v
> v that no longer existed.  The docstring doesn't mention the case where
> Emacs' idea of the file's status is out of date.

Re: VC and bzr.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I find the status indicator (the `:' or `-' chars that flags a file as
>> modified on disk or not) very helpful.
>
> They don't get updated unless you revert the buffer, or do all your VC
> ops from within Emacs.  So they lie to me quite a bit.

I do almost all VC ops from within Emacs, so they are fine. Although VC
doesn't cover all often-used ops for dVCS, packages like magit.el just
require a bit of customization for refresing the VC status after an
operation.

>> IMHO, it is wrong to cut down global VC features just because some
>> backend is slow.
>
> This has nothing to do with slowness, see my message for the details.

Unless I completely misunderstood, slowness is at the root of the issue,
but if you prefer turn my comment into "IMHO, it is wrong to cut down
global VC features just because some backend is broken"

Re: VC and bzr.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 23 Apr 2010 22:31:58 +0200
> 
> Unless I completely misunderstood, slowness is at the root of the issue,

No, it isn't; not unless you consider a few seconds taken by a commit
to be ``slow''.

> but if you prefer turn my comment into "IMHO, it is wrong to cut down
> global VC features just because some backend is broken"

It's not ``some backend'', it's _the_ backend for Emacs development.

Re: VC and bzr.

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Fri, 23 Apr 2010 22:31:58 +0200
>> 
>> Unless I completely misunderstood, slowness is at the root of the issue,
>
> No, it isn't; not unless you consider a few seconds taken by a commit
> to be ``slow''.

>> but if you prefer turn my comment into "IMHO, it is wrong to cut down
>> global VC features just because some backend is broken"
>
> It's not ``some backend'', it's _the_ backend for Emacs development.

The number of Emacs developers is tiny compared to the number of Emacs
users.  And even for Emacs developers, the time they spend developing
Emacs is a small fraction of their time...
So please don't break useful VC features because bzr is not ideal.

Re: VC and bzr.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

>> but if you prefer turn my comment into "IMHO, it is wrong to cut down
>> global VC features just because some backend is broken"
>
> It's not ``some backend'', it's _the_ backend for Emacs development.

I don't know why those Emacs users who use Subversion, Git, Mercurial
etc may see how some convenient feature go away just because the VCS
used for Emacs development is... not as fast as others.

Following the true Emacs spirit, is it a good idea to introduce a
backend-specific variable for selectively enabling/disabling the VC info
shown on the modeline? It would be set to a sensible default for each
backend.

Re: VC and bzr.

[Juanma Barranquero]

On Fri, Apr 23, 2010 at 22:43, Eli Zaretskii <eliz@gnu.org> wrote:

> It's not ``some backend'', it's _the_ backend for Emacs development.

Even so, removing useful features (I totally agree with Óscar here)
because _the_ backend is broken is just bad.

    Juanma

Re: VC and bzr.

[Andreas Schwab]

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

> merge from trunk into my feature branch
> then, push to trunk

You should never use such a workflow, of course.  Nobody is suggesting
that.

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: VC and bzr.

[Óscar Fuentes]

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

>> merge from trunk into my feature branch
>> then, push to trunk
>
> You should never use such a workflow, of course.  Nobody is suggesting
> that.

So how shall I interpret this:

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

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>> Yes, I know I have a few local branches.  But sometimes it has to go to
>> savannah, or it will always be your private work.
>
> So push it when and only when it's ready.

I read your advice as "use `bzr push'".

Maybe by "push" you mean "commit" ?

(The workflow described on the wiki is equivalent to pulling from trunk,
not pushing into it, which makes a big difference on bzr because the
special treatment it gives to the leftmost part of the DAG as discussed
before.)

Re: VC and bzr.

[Andreas Schwab]

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

> Maybe by "push" you mean "commit" ?

No, push means exactly that.

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: VC and bzr.

[Jan D.]

Andreas Schwab wrote:
> "Jan D." <jan.h.d@swipnet.se> writes:
> 
>> Andreas Schwab wrote:
>>> "Jan D." <jan.h.d@swipnet.se> writes:
>>>
>>>> Yes, I know I have a few local branches.  But sometimes it has to go to
>>>> savannah, or it will always be your private work.
>>> So push it when and only when it's ready.
>>>
>> Push takes the same amount of time.
> 
> You only need to contact the server for the push, not for every commit.

I don't commit every small change from task branches.  But sometimes 
compilation is broken and it is a small change that better be commited 
as fast as possible.  Or it is indeed just a small change.

> 
>> There is advantage to commit from VC, Changelogs and vl-logs are
>> available in buffers for example.
> 
> Commits work the same.

That statement makes no sense.  Same as what?

	Jan D.

Re: VC and bzr.

[Andreas Schwab]

"Jan D." <jan.h.d@swipnet.se> writes:

>>> There is advantage to commit from VC, Changelogs and vl-logs are
>>> available in buffers for example.
>>
>> Commits work the same.
>
> That statement makes no sense.  Same as what?

Independent of the branch configuration (whether --checkout or --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."