* 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-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 ` (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-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 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 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 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: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 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 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 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).