unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Change to bzr build instructions
@ 2011-03-21  0:24 Glenn Morris
  2011-03-21  0:46 ` Glenn Morris
                   ` (6 more replies)
  0 siblings, 7 replies; 30+ messages in thread
From: Glenn Morris @ 2011-03-21  0:24 UTC (permalink / raw)
  To: emacs-devel


The following only applies to platforms that use the configure script.

The autotools generated files such as configure are no longer present in
the repository in the trunk. Instead you should generate them yourself
using the autogen.sh script. See INSTALL.BZR for details.

Developers: there is no longer any need to commit autotools generated
files. The versions in autogen/ will hopefully be kept up-to-date by a
daily cron job running on fencepost.

I look forward to it all blowing up in 3,2,...



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-21  0:24 Change to bzr build instructions Glenn Morris
@ 2011-03-21  0:46 ` Glenn Morris
  2011-03-21 16:06 ` Jim Meyering
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 30+ messages in thread
From: Glenn Morris @ 2011-03-21  0:46 UTC (permalink / raw)
  To: emacs-devel


PS If you have been running autoconf etc locally, you will probably have
conflicts that need resolving the next time you update from bzr, due to
the removal of files that you have locally modified.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-21  0:24 Change to bzr build instructions Glenn Morris
  2011-03-21  0:46 ` Glenn Morris
@ 2011-03-21 16:06 ` Jim Meyering
  2011-03-21 22:33 ` Stefan Monnier
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 30+ messages in thread
From: Jim Meyering @ 2011-03-21 16:06 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

Glenn Morris wrote:
> The following only applies to platforms that use the configure script.
>
> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.
>
> Developers: there is no longer any need to commit autotools generated
> files. The versions in autogen/ will hopefully be kept up-to-date by a
> daily cron job running on fencepost.

Nice.  Thanks for doing that!



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-21  0:24 Change to bzr build instructions Glenn Morris
  2011-03-21  0:46 ` Glenn Morris
  2011-03-21 16:06 ` Jim Meyering
@ 2011-03-21 22:33 ` Stefan Monnier
  2011-03-22  3:31   ` Glenn Morris
  2011-03-22  9:32 ` Andreas Schwab
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2011-03-21 22:33 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.

I just tried it on a machine whose autoconf is older than 2.65 and while
I got it to work, there are some problems.  Mostly the problem is that
after running copy_autogen, it still tried to run autoheader.  I had to
"touch src/stamp-h.in".  So we should either be more careful about such
dependencies in copy_autogen, or maybe try and get copy_autogen to set
"enable-maintainer-mode=off".

Another (minor) problem is that it's a lot more convenient to run
./autogen/copy than to cd into autogen to run ./copy and then cd back
out of it.


        Stefan



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-21 22:33 ` Stefan Monnier
@ 2011-03-22  3:31   ` Glenn Morris
  2011-03-22  5:42     ` Stefan Monnier
  0 siblings, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2011-03-22  3:31 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier wrote:

>  Mostly the problem is that after running copy_autogen, it still tried
> to run autoheader. I had to "touch src/stamp-h.in".

I added that, basically.

> So we should either be more careful about such dependencies in
> copy_autogen, or maybe try and get copy_autogen to set
> "enable-maintainer-mode=off".

I suppose it could do something like that, but I don't know if it is a
good idea. I really don't recommend the use of the copy_autogen script
at all, except very much as a last resort, so I wouldn't want to see it
get too fancy.

> Another (minor) problem is that it's a lot more convenient to run
> ./autogen/copy than to cd into autogen to run ./copy and then cd back
> out of it.

OK, now either works.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-22  3:31   ` Glenn Morris
@ 2011-03-22  5:42     ` Stefan Monnier
  2011-03-22  7:16       ` Glenn Morris
  0 siblings, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2011-03-22  5:42 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

>> Mostly the problem is that after running copy_autogen, it still tried
>> to run autoheader. I had to "touch src/stamp-h.in".
> I added that, basically.

Good, thanks.

>> So we should either be more careful about such dependencies in
>> copy_autogen, or maybe try and get copy_autogen to set
>> "enable-maintainer-mode=off".
> I suppose it could do something like that, but I don't know if it is a
> good idea. I really don't recommend the use of the copy_autogen script
> at all, except very much as a last resort, so I wouldn't want to see it
> get too fancy.

I don't think we want to get too fancy, indeed.  The `touch' trick seems
sufficient for now.

>> Another (minor) problem is that it's a lot more convenient to run
>> ./autogen/copy than to cd into autogen to run ./copy and then cd back
>> out of it.
> OK, now either works.

Great, thanks,


        Stefan



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-22  5:42     ` Stefan Monnier
@ 2011-03-22  7:16       ` Glenn Morris
  2011-03-22  8:08         ` Jim Meyering
  0 siblings, 1 reply; 30+ messages in thread
From: Glenn Morris @ 2011-03-22  7:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel


>>> So we should either be more careful about such dependencies in
>>> copy_autogen, or maybe try and get copy_autogen to set
>>> "enable-maintainer-mode=off".
>> I suppose it could do something like that, but I don't know if it is a
>> good idea. I really don't recommend the use of the copy_autogen script
>> at all, except very much as a last resort, so I wouldn't want to see it
>> get too fancy.
>
> I don't think we want to get too fancy, indeed.  The `touch' trick seems
> sufficient for now.

To elaborate, if the autogen/configure script is one with
maintainer-mode = off by default, then if someone uses it, they won't
get any prompting to update configure if configure.in changes in the
repository. At least with the current situation, they will get an error
about missing autotools, which will hopefully prompt them to run
copy_autogen again.


On this subject, what to do about maintainer-mode in releases?
At present, I put a note in admin/make-tarball.txt saying that the
configure in a release tarfile should be generated with maintainer-mode
off.

i) It's rather poor to have to remember to change that.

ii) Is it actually necessary to make such a distinction?
If configure.in etc are not changed, it does not matter, and if someone
does edit configure.in, arguably they _should_ get an updated configure.
This seems to be what automake recommends now:

http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html

(or is it actually recommending removing the option altogether, and
having it always on?)



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-22  7:16       ` Glenn Morris
@ 2011-03-22  8:08         ` Jim Meyering
  0 siblings, 0 replies; 30+ messages in thread
From: Jim Meyering @ 2011-03-22  8:08 UTC (permalink / raw)
  To: Glenn Morris; +Cc: Stefan Monnier, emacs-devel

Glenn Morris wrote:
>>>> So we should either be more careful about such dependencies in
>>>> copy_autogen, or maybe try and get copy_autogen to set
>>>> "enable-maintainer-mode=off".
>>> I suppose it could do something like that, but I don't know if it is a
>>> good idea. I really don't recommend the use of the copy_autogen script
>>> at all, except very much as a last resort, so I wouldn't want to see it
>>> get too fancy.
>>
>> I don't think we want to get too fancy, indeed.  The `touch' trick seems
>> sufficient for now.
>
> To elaborate, if the autogen/configure script is one with
> maintainer-mode = off by default, then if someone uses it, they won't
> get any prompting to update configure if configure.in changes in the
> repository. At least with the current situation, they will get an error
> about missing autotools, which will hopefully prompt them to run
> copy_autogen again.
>
>
> On this subject, what to do about maintainer-mode in releases?
> At present, I put a note in admin/make-tarball.txt saying that the
> configure in a release tarfile should be generated with maintainer-mode
> off.
>
> i) It's rather poor to have to remember to change that.
>
> ii) Is it actually necessary to make such a distinction?
> If configure.in etc are not changed, it does not matter, and if someone
> does edit configure.in, arguably they _should_ get an updated configure.
> This seems to be what automake recommends now:
>
> http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html

Yes.

> (or is it actually recommending removing the option altogether, and
> having it always on?)

It is recommending never to use the AM_MAINTAINER_MODE macro, and
explains how its use can cause trouble.  When you don't use the macro,
that is like making configure always use --enable-maintainer-mode.

Very early on (like right after adding it), I found that maintainer
mode was causing more problems than it solved.

Now, with complete and robust auto*-running rules in nearly
all Makefiles (in the early years, that was actually a problem)
and relatively modern and compatible autoconf and automake,
I find that there is little need for maintainer mode.
(but then I never VC files it generates, either)

I argue that if someone changes Makefile.am or configure.ac
and that does not cause a rule to rerun the proper tools
to update all dependents, then *that* is a bug.

A common argument in favor of --maintainer-mode is that it helps
protect users who change those files without realizing they would
then have to have reasonably modern build-from-clone tools installed.

These days, people are far more likely to know that those tools
may be required than they were when --maintainer-mode was added.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-21  0:24 Change to bzr build instructions Glenn Morris
                   ` (2 preceding siblings ...)
  2011-03-21 22:33 ` Stefan Monnier
@ 2011-03-22  9:32 ` Andreas Schwab
  2011-03-23  3:15   ` Glenn Morris
  2011-03-22 11:36 ` Andreas Röhler
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 30+ messages in thread
From: Andreas Schwab @ 2011-03-22  9:32 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

Glenn Morris <rgm@gnu.org> writes:

> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.

You should also remove all the other files that would be added by
running autoreconf (config.{guess,sub}, depcomp, missing, etc.).

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



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-21  0:24 Change to bzr build instructions Glenn Morris
                   ` (3 preceding siblings ...)
  2011-03-22  9:32 ` Andreas Schwab
@ 2011-03-22 11:36 ` Andreas Röhler
  2011-03-22 13:09 ` Harald Hanche-Olsen
  2011-03-25  9:54 ` Eli Zaretskii
  6 siblings, 0 replies; 30+ messages in thread
From: Andreas Röhler @ 2011-03-22 11:36 UTC (permalink / raw)
  To: emacs-devel

Am 21.03.2011 01:24, schrieb Glenn Morris:
>
> The following only applies to platforms that use the configure script.
>
> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.
>
> Developers: there is no longer any need to commit autotools generated
> files. The versions in autogen/ will hopefully be kept up-to-date by a
> daily cron job running on fencepost.
>
> I look forward to it all blowing up in 3,2,...
>
>

Hi,

got today:

  ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)

Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains: 
/usr/share/autoconf /usr/lib/perl5/5.10.0/i586-linux-thread-multi 
/usr/lib/perl5/5.10.0 
/usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi 
/usr/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at 
/usr/bin/autoreconf line 42.
BEGIN failed--compilation aborted at /usr/bin/autoreconf line 42.


on Suse-11.2
Linux 2.6.31.14-0.6-default #1 SMP 2010-12-10 11:18:32 +0100 i686 i686 
i386 GNU/Linux

BTW this installation seems to have some odds, error might be here.

Thanks


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/






^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-21  0:24 Change to bzr build instructions Glenn Morris
                   ` (4 preceding siblings ...)
  2011-03-22 11:36 ` Andreas Röhler
@ 2011-03-22 13:09 ` Harald Hanche-Olsen
  2011-03-22 18:37   ` Glenn Morris
  2011-03-25  9:54 ` Eli Zaretskii
  6 siblings, 1 reply; 30+ messages in thread
From: Harald Hanche-Olsen @ 2011-03-22 13:09 UTC (permalink / raw)
  To: emacs-devel

[Glenn Morris <rgm@gnu.org> (2011-03-21 00:24:50 UTC)]

> The autotools generated files such as configure are no longer present in
> the repository in the trunk. Instead you should generate them yourself
> using the autogen.sh script. See INSTALL.BZR for details.

I got the following result:

; ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.BZR for more details on building Emacs)

Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Your system has the required tools, running autoreconf...
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 189.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 189.
You can now run `./configure'.

Apparently, that is a successful run despite the errors?

- Harald



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-22 13:09 ` Harald Hanche-Olsen
@ 2011-03-22 18:37   ` Glenn Morris
  0 siblings, 0 replies; 30+ messages in thread
From: Glenn Morris @ 2011-03-22 18:37 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-devel

Harald Hanche-Olsen wrote:

> Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 189.
> Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 189.
> You can now run `./configure'.

Sorry, I don't understand that. Emacs does not use libtool (AFAIK), and
it works fine for me on a system without it installed. Perhaps it is a
bug in whatever your version of autoreconf is? In any case, it still
exits with status 0, so I think this is just a cosmetic issue that you
can ignore.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-22  9:32 ` Andreas Schwab
@ 2011-03-23  3:15   ` Glenn Morris
  0 siblings, 0 replies; 30+ messages in thread
From: Glenn Morris @ 2011-03-23  3:15 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: emacs-devel

Andreas Schwab wrote:

> You should also remove all the other files that would be added by
> running autoreconf (config.{guess,sub}, depcomp, missing, etc.).

Awesome, I'll remove them in a few days if no-one objects; and make the
required changes to autogen.sh, autogen/, etc.

I think the list is:

compile config.guess config.sub depcomp install-sh missing

(technically could also do texinfo.tex, but I won't)

The only reason I can see to keep some or all of these files is if for
some reason Emacs has to have the very latest version (compared to what
automake 1.11 supplies).



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-21  0:24 Change to bzr build instructions Glenn Morris
                   ` (5 preceding siblings ...)
  2011-03-22 13:09 ` Harald Hanche-Olsen
@ 2011-03-25  9:54 ` Eli Zaretskii
  2011-03-25 10:04   ` David Kastrup
  6 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2011-03-25  9:54 UTC (permalink / raw)
  To: Glenn Morris; +Cc: emacs-devel

> From: Glenn Morris <rgm@gnu.org>
> Date: Sun, 20 Mar 2011 20:24:50 -0400
> 
> 
> The autotools generated files such as configure are no longer present in
> the repository in the trunk.

Why were these files deleted and then created anew in autogen/?  Why
not "bzr mv" them instead?  Do we really want to lose their history?



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25  9:54 ` Eli Zaretskii
@ 2011-03-25 10:04   ` David Kastrup
  2011-03-25 10:18     ` Eli Zaretskii
  0 siblings, 1 reply; 30+ messages in thread
From: David Kastrup @ 2011-03-25 10:04 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Glenn Morris <rgm@gnu.org>
>> Date: Sun, 20 Mar 2011 20:24:50 -0400
>> 
>> 
>> The autotools generated files such as configure are no longer present
>> in the repository in the trunk.
>
> Why were these files deleted and then created anew in autogen/?  Why
> not "bzr mv" them instead?  Do we really want to lose their history?

One thing that makes sense about git: moving files is exactly the same
as deleting and recreating them.  History is reconstructed on the fly
when you ask for it and tracks the contents, not the file names (though
they provide starting points for he heuristics).  So you don't depend on
the programmer telling the system how content moved about.

-- 
David Kastrup




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 10:04   ` David Kastrup
@ 2011-03-25 10:18     ` Eli Zaretskii
  2011-03-25 11:44       ` Leo
  0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2011-03-25 10:18 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 25 Mar 2011 11:04:24 +0100
> 
> > Why were these files deleted and then created anew in autogen/?  Why
> > not "bzr mv" them instead?  Do we really want to lose their history?
> 
> One thing that makes sense about git: moving files is exactly the same
> as deleting and recreating them.

Please stop the git propaganda here.  The advantages and disadvantages
of git vs bzr in this regard are well known and can be found with
Google.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 10:18     ` Eli Zaretskii
@ 2011-03-25 11:44       ` Leo
  2011-03-25 13:07         ` David Kastrup
                           ` (4 more replies)
  0 siblings, 5 replies; 30+ messages in thread
From: Leo @ 2011-03-25 11:44 UTC (permalink / raw)
  To: emacs-devel

On 2011-03-25 18:18 +0800, Eli Zaretskii wrote:
> Please stop the git propaganda here.  The advantages and disadvantages
> of git vs bzr in this regard are well known and can be found with
> Google.

I see no propaganda here. David merely mentions the way git handles
renames etc which is obviously better than bzr's. Why would bzr insist
people remember to use bzr mv instead of the shell command mv?

BTW, having used bzr recently I have realised how restrictive that tool
is!

Leo




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 11:44       ` Leo
@ 2011-03-25 13:07         ` David Kastrup
  2011-03-25 13:13         ` Eli Zaretskii
                           ` (3 subsequent siblings)
  4 siblings, 0 replies; 30+ messages in thread
From: David Kastrup @ 2011-03-25 13:07 UTC (permalink / raw)
  To: emacs-devel

Leo <sdl.web@gmail.com> writes:

> On 2011-03-25 18:18 +0800, Eli Zaretskii wrote:
>> Please stop the git propaganda here.  The advantages and disadvantages
>> of git vs bzr in this regard are well known and can be found with
>> Google.
>
> I see no propaganda here.  David merely mentions the way git handles
> renames etc which is obviously better than bzr's.

Uh, git does not "handle" renames, tracking them not at all.  That's not
actually "better" (and in fact, git history, particularly annotating and
blaming is not the fastest as one consequence of this design choice).
But it leaves one less opportunity for manual mistakes.

> Why would bzr insist people remember to use bzr mv instead of the
> shell command mv?

Because it is a different approach.  Explicit information, when given,
beats guesswork.  One has to keep in mind that Linux, for which git was
designed, is a large-scale fast-turnaround software system with vast
amounts of information flow and very widely distributed responsibility
and mergeflows.  Maintaining any side information manually (like we do
with ChangeLog files) is more likely to be affected by shoddiness.  We
all know how much fun the ChangeLog files and their merges are in
distributed development.  When people try doing the same things with
slightly different workflow, it is convenient when no conflicts occur as
a result.  So git took the design choice of not even remembering things
that may or may not be shoddily maintained as "side information".

With Bzr, people need to remember to _give_ this information explicitly.
And of course this is relevant for Emacs developers using Bzr directly.

-- 
David Kastrup




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 11:44       ` Leo
  2011-03-25 13:07         ` David Kastrup
@ 2011-03-25 13:13         ` Eli Zaretskii
  2011-03-25 13:52           ` David Kastrup
  2011-03-25 13:45         ` Andreas Röhler
                           ` (2 subsequent siblings)
  4 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2011-03-25 13:13 UTC (permalink / raw)
  To: Leo; +Cc: emacs-devel

> From: Leo <sdl.web@gmail.com>
> Date: Fri, 25 Mar 2011 19:44:19 +0800
> 
> David merely mentions the way git handles renames etc which is
> obviously better than bzr's.

It's not obviously better.

> Why would bzr insist people remember to use bzr mv instead of the
> shell command mv?

Because that way, there's no heuristics involved in inferring whether
a file was renamed or not.  With bzr, renaming while also modifying
the file's contents can be safely done in one commit instead of two.

> BTW, having used bzr recently I have realised how restrictive that tool
> is!

You need to learn how to use it and you need to "think Bazaar", not
git.

If you have constructive criticism and proposals, please post them to
bazaar@lists.canonical.com.  This forum is not the appropriate place
to discuss that, unless the issue is closely related to Emacs.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 11:44       ` Leo
  2011-03-25 13:07         ` David Kastrup
  2011-03-25 13:13         ` Eli Zaretskii
@ 2011-03-25 13:45         ` Andreas Röhler
  2011-03-27 18:54           ` Davis Herring
  2011-03-25 14:37         ` Ted Zlatanov
  2011-03-25 19:55         ` Stefan Monnier
  4 siblings, 1 reply; 30+ messages in thread
From: Andreas Röhler @ 2011-03-25 13:45 UTC (permalink / raw)
  To: emacs-devel

[ .. ] Why would bzr insist
> people remember to use bzr mv instead of the shell command mv?

[ ... ]

Does it?

When copying whole bzr-directories with shell didn't notice a loss. (?)

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 13:13         ` Eli Zaretskii
@ 2011-03-25 13:52           ` David Kastrup
  2011-03-25 16:02             ` Eli Zaretskii
  0 siblings, 1 reply; 30+ messages in thread
From: David Kastrup @ 2011-03-25 13:52 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Leo <sdl.web@gmail.com>
>
>> Why would bzr insist people remember to use bzr mv instead of the
>> shell command mv?
>
> Because that way, there's no heuristics involved in inferring whether
> a file was renamed or not.  With bzr, renaming while also modifying
> the file's contents can be safely done in one commit instead of two.

Safety does not come into play here.  You can, of course, do the same in
git.  If you do this frequently, it makes sense to tell git to work
harder when reconstructing history.  When you do, git can also make
sense out of material factored out from several files into a single one
and vice versa, something which can't be told bzr as far as I know.

Of course, you need to _know_ when it will be helpful to ask for more,
and it might be an easier choice for the person actually doing the
checkin.  While it is usually easier to ask an automated tool for
working harder right now than a human, as long as the respective
information is likely to be read more often than written, letting the
human do the work while he still has complete knowledge about what he is
doing is a reasonable tradeoff.

The problem is when people consider it likely that nobody will actually
need this information: in that case still writing it requires
discipline.

And Eli asked for keeping this discipline because it makes life easier
in the long run given our choice of tools.

-- 
David Kastrup




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 11:44       ` Leo
                           ` (2 preceding siblings ...)
  2011-03-25 13:45         ` Andreas Röhler
@ 2011-03-25 14:37         ` Ted Zlatanov
  2011-03-25 15:03           ` David Kastrup
  2011-03-25 19:55         ` Stefan Monnier
  4 siblings, 1 reply; 30+ messages in thread
From: Ted Zlatanov @ 2011-03-25 14:37 UTC (permalink / raw)
  To: emacs-devel

On Fri, 25 Mar 2011 19:44:19 +0800 Leo <sdl.web@gmail.com> wrote: 

L> On 2011-03-25 18:18 +0800, Eli Zaretskii wrote:
>> Please stop the git propaganda here.  The advantages and disadvantages
>> of git vs bzr in this regard are well known and can be found with
>> Google.

L> I see no propaganda here. David merely mentions the way git handles
L> renames etc which is obviously better than bzr's. Why would bzr insist
L> people remember to use bzr mv instead of the shell command mv?

David's post was completely besides the point.  Eli was asking people to
use "bzr mv" which is reasonable.  What does it matter how Git does it?

L> BTW, having used bzr recently I have realised how restrictive that tool
L> is!

Bazaar is no git[1] and Git is no bazaar.  There, it's settled.

Ted

[1] http://www.urbandictionary.com/define.php?term=git




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 14:37         ` Ted Zlatanov
@ 2011-03-25 15:03           ` David Kastrup
  2011-03-25 15:16             ` Ted Zlatanov
  2011-03-25 16:08             ` Eli Zaretskii
  0 siblings, 2 replies; 30+ messages in thread
From: David Kastrup @ 2011-03-25 15:03 UTC (permalink / raw)
  To: emacs-devel

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 25 Mar 2011 19:44:19 +0800 Leo <sdl.web@gmail.com> wrote: 
>
> L> On 2011-03-25 18:18 +0800, Eli Zaretskii wrote:
>>> Please stop the git propaganda here.  The advantages and disadvantages
>>> of git vs bzr in this regard are well known and can be found with
>>> Google.
>
> L> I see no propaganda here. David merely mentions the way git handles
> L> renames etc which is obviously better than bzr's. Why would bzr insist
> L> people remember to use bzr mv instead of the shell command mv?
>
> David's post was completely besides the point.  Eli was asking people to
> use "bzr mv" which is reasonable.  What does it matter how Git does it?

Because one can presumably use

    bzr git-apply

or

    bzr git-import

in order to get automated move information from a local git mirror into
Bazaar if one wants to avoid remembering to specify moves manually each
time?

-- 
David Kastrup




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 15:03           ` David Kastrup
@ 2011-03-25 15:16             ` Ted Zlatanov
  2011-03-25 15:32               ` David Kastrup
  2011-03-25 16:08             ` Eli Zaretskii
  1 sibling, 1 reply; 30+ messages in thread
From: Ted Zlatanov @ 2011-03-25 15:16 UTC (permalink / raw)
  To: emacs-devel

On Fri, 25 Mar 2011 16:03:52 +0100 David Kastrup <dak@gnu.org> wrote: 

>> David's post was completely besides the point.  Eli was asking people to
>> use "bzr mv" which is reasonable.  What does it matter how Git does it?

DK> Because one can presumably use

DK>     bzr git-apply

DK> or

DK>     bzr git-import

DK> in order to get automated move information from a local git mirror into
DK> Bazaar if one wants to avoid remembering to specify moves manually each
DK> time?

I was not aware of that plugin, thanks for explaining (I found more
details at https://launchpad.net/bzr-git).  So really you were saying
"if you use the bzr-git plugin you could avoid these mistakes" which is
a different message :)

Ted




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 15:16             ` Ted Zlatanov
@ 2011-03-25 15:32               ` David Kastrup
  0 siblings, 0 replies; 30+ messages in thread
From: David Kastrup @ 2011-03-25 15:32 UTC (permalink / raw)
  To: emacs-devel

Ted Zlatanov <tzz@lifelogs.com> writes:

> I was not aware of that plugin, thanks for explaining (I found more
> details at https://launchpad.net/bzr-git).  So really you were saying
> "if you use the bzr-git plugin you could avoid these mistakes" which is
> a different message :)

I was not really saying that at first.  Instead I shamelessly used the
situation after the fact for supplying hopefully useful information
after all.

-- 
David Kastrup




^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 13:52           ` David Kastrup
@ 2011-03-25 16:02             ` Eli Zaretskii
  0 siblings, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2011-03-25 16:02 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 25 Mar 2011 14:52:33 +0100
> 
> And Eli asked for keeping this discipline because it makes life easier
> in the long run given our choice of tools.

Actually, my main problem is forensics: the ability to tell which
commit made a certain change.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 15:03           ` David Kastrup
  2011-03-25 15:16             ` Ted Zlatanov
@ 2011-03-25 16:08             ` Eli Zaretskii
  1 sibling, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2011-03-25 16:08 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 25 Mar 2011 16:03:52 +0100
> 
> Because one can presumably use
> 
>     bzr git-apply
> 
> or
> 
>     bzr git-import
> 
> in order to get automated move information from a local git mirror into
> Bazaar if one wants to avoid remembering to specify moves manually each
> time?

If you have bzr-git installed, you can simply say "bzr merge" or "bzr
pull".

IOW, that plugin makes git repositories first-class bzr citizens
(except that "bzr push" doesn't work yet, so you can only use the git
repo in read-only mode).  I actually use this to track several git
repositories, and my experience is very good, with a single exception:
the original "bzr branch" command is painfully slow for repositories
with many revisions, because the step that computes bzr metadata from
git takes a very long time (I filed a bug report about that).



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 11:44       ` Leo
                           ` (3 preceding siblings ...)
  2011-03-25 14:37         ` Ted Zlatanov
@ 2011-03-25 19:55         ` Stefan Monnier
  2011-03-28  1:11           ` Miles Bader
  4 siblings, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2011-03-25 19:55 UTC (permalink / raw)
  To: Leo; +Cc: emacs-devel

>> Please stop the git propaganda here.  The advantages and disadvantages
>> of git vs bzr in this regard are well known and can be found with
>> Google.
> I see no propaganda here.

That's just because you're biased, like we all are.  It's not relevant
to emacs-devel, so let's please stop this discussion right there.
Emacs is using Bazaar, so what git does is irrelevant.
As for the original post, yes, "bzr mv" would have been better.
These aren't files where history is important, but we need to remember
to do it better as a matter of course.


        Stefan



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 13:45         ` Andreas Röhler
@ 2011-03-27 18:54           ` Davis Herring
  0 siblings, 0 replies; 30+ messages in thread
From: Davis Herring @ 2011-03-27 18:54 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: emacs-devel

>> [ .. ] Why would bzr insist
>> people remember to use bzr mv instead of the shell command mv?
>
> Does it?
>
> When copying whole bzr-directories with shell didn't notice a loss. (?)

This is for moves within (not of) working copies that one intends to commit.

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.



^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: Change to bzr build instructions
  2011-03-25 19:55         ` Stefan Monnier
@ 2011-03-28  1:11           ` Miles Bader
  0 siblings, 0 replies; 30+ messages in thread
From: Miles Bader @ 2011-03-28  1:11 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Leo, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I see no propaganda here.
>
> That's just because you're biased, like we all are.  It's not relevant
> to emacs-devel, so let's please stop this discussion right there.

But note that even if some people don't like anti-bzr comments,
_replying_ to them is probably more counter-productive than the comments
themselves:  such comments aren't going to stop, so there's little point
in trying to stop them, and there's no need to turn them into threads...

-Miles

-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))



^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2011-03-28  1:11 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-21  0:24 Change to bzr build instructions Glenn Morris
2011-03-21  0:46 ` Glenn Morris
2011-03-21 16:06 ` Jim Meyering
2011-03-21 22:33 ` Stefan Monnier
2011-03-22  3:31   ` Glenn Morris
2011-03-22  5:42     ` Stefan Monnier
2011-03-22  7:16       ` Glenn Morris
2011-03-22  8:08         ` Jim Meyering
2011-03-22  9:32 ` Andreas Schwab
2011-03-23  3:15   ` Glenn Morris
2011-03-22 11:36 ` Andreas Röhler
2011-03-22 13:09 ` Harald Hanche-Olsen
2011-03-22 18:37   ` Glenn Morris
2011-03-25  9:54 ` Eli Zaretskii
2011-03-25 10:04   ` David Kastrup
2011-03-25 10:18     ` Eli Zaretskii
2011-03-25 11:44       ` Leo
2011-03-25 13:07         ` David Kastrup
2011-03-25 13:13         ` Eli Zaretskii
2011-03-25 13:52           ` David Kastrup
2011-03-25 16:02             ` Eli Zaretskii
2011-03-25 13:45         ` Andreas Röhler
2011-03-27 18:54           ` Davis Herring
2011-03-25 14:37         ` Ted Zlatanov
2011-03-25 15:03           ` David Kastrup
2011-03-25 15:16             ` Ted Zlatanov
2011-03-25 15:32               ` David Kastrup
2011-03-25 16:08             ` Eli Zaretskii
2011-03-25 19:55         ` Stefan Monnier
2011-03-28  1:11           ` Miles Bader

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).