GIT and CVS

GIT and CVS

[Phil Muldoon]

At the risk of atomizing the poor horse, I want to refresh ideas and
thoughts on this.  

First, I'll point out I am in favor of GIT.  Not because GIT has won me
over heart-and-soul, but purely because I can work on GDB GIT offline.
This is not an inconsiderable benefit.  I can create local check-ins,
create branches, merge, cherry-pick all in the leisure of my own office,
or garden, or airport ... without internet access.

So that is my bias laid out.

So why are we still on CVS?  I'm not a release manager, so I do not have
to do the difficult work of cutting branches, and all of the difficult
work in making releases.  But what are the objections to GIT?
Personally, I'll give a strong bias to Joel's opinions because, frankly,
he has to deal with this issue far more than any other. 

GIT is, I think, available everywhere, has a CVS interface, and is
far, far quicker than CVS.  Maybe with the stronger identity and
information that comes with GIT logs we can finally retire
ChangeLogs.

CVS has served very well over the years.  I, and many others, cut our
teeth on it.  It's been a good system.  But beyond stability I
don't see it keeping up with functionality of other repository systems.
I find myself working on GIT 98% of the time, and the other 2% dealing
with CVS on the final check-in.  Surely I can't be the only hacker that
does this?  If the vast majority are in this work-flow, perhaps we
should think about the pros and the cons again.  I have no ideas about
the work-flows of my GDB hackers, and if, you know, we are all doing this
then we should recognize the elephant in the room.  If not, then I will
go happily into the (CVS) night, content on the validity of its use and
utility.

So, what do you think?

Cheers,
 
Phil

Re: GIT and CVS

[Joseph S. Myers]

On Thu, 13 Oct 2011, Phil Muldoon wrote:

> So why are we still on CVS?  I'm not a release manager, so I do not have

Because the complications associated with having many projects in the same 
repository are a lot of work to disentangle, and it is a lot of work to do 
the conversion (including all the infrastructure scripts, user 
instructions etc.) for any one project.

I think binutils+gdb is the right unit to aim for getting into a separate 
repository, as discussed in 
<http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.

> far, far quicker than CVS.  Maybe with the stronger identity and
> information that comes with GIT logs we can finally retire
> ChangeLogs.

ChangeLogs are very useful whatever the version control system; it's 
routine to import snapshots from one system into another and the 
ChangeLogs are readily available to see what source version you actually 
have there.  ChangeLogs are convenient to grep and much less I/O intensive 
than git operations are (especially when your checkout is on NFS).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GIT and CVS

[Phil Muldoon]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Thu, 13 Oct 2011, Phil Muldoon wrote:
>
>> So why are we still on CVS?  I'm not a release manager, so I do not have
>
> Because the complications associated with having many projects in the same 
> repository are a lot of work to disentangle, and it is a lot of work to do 
> the conversion (including all the infrastructure scripts, user 
> instructions etc.) for any one project.
>
> I think binutils+gdb is the right unit to aim for getting into a separate 
> repository, as discussed in 
> <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.

Ok, thanks for your response.  Beyond the reason why they were in the
same repository for how many years, why do they still have to be?

I can understand that projects so closely involved need to be in
lock-step in their release objectives, but with healthy communities for
each project, do they need to be still?

I think though, I am missing the point.  If GDB decides, on its own, to
go with GIT, what happens to the other projects?  What are the outcomes?
I just do not understand why this is a problem, and I wish somebody
could just tell me the problems.  Can they continue on CVS without harm?
Could we persuade them about GIT too? Is it a problem with long CVS
history? What are the problems here?

I hack on GDB, and I really don't hack on much else.  This is not to
diminish other projects, I just don't hack on them.  While other modules
represented by other projects are important, I am trying to understand
the reason why this is a blocker?  Building GDB requires a lot of
dependencies outside of what is provided in the repository.

> ChangeLogs are very useful whatever the version control system; it's 
> routine to import snapshots from one system into another and the 
> ChangeLogs are readily available to see what source version you actually 
> have there.  ChangeLogs are convenient to grep and much less I/O intensive 
> than git operations are (especially when your checkout is on NFS).

I nearly decided to delete that line from the email as I did not want to
dilute the arguments.  I wrote the ChangeLog parser for Eclipse as I found
ChangeLogs tiresome to write when history basically replaced it.  I must
admit, even when I hack on emacs, it is still a pain.  I'll continue to
do it, if people find it useful.  However, git log is very, highly
configurable.  The options are very broad.  And, as you can generate a
git log from a local repository, the NFS thing should not be too
difficult to overcome?

Cheers,

Phil

Re: GIT and CVS

[DJ Delorie]

My old argument is... How many copies of libiberty do you want to
maintain?  How many copies of bfd?  of the toplevel build machinery?  Of
include or libdecnumber or whatnot?

Also, ChangeLogs survive a release tarball, commit history doesn't.

(personally, though, I just don't like using git)

Re: GIT and CVS

[Phil Muldoon]

DJ Delorie <dj@redhat.com> writes:

> My old argument is... How many copies of libiberty do you want to
> maintain?  How many copies of bfd?  of the toplevel build machinery?  Of
> include or libdecnumber or whatnot?

One, and one only.  I'm just trying to understand why these separate
projects are hosted alongside GDB.  And why they should continue to be.
I am not being dismissive, or stand-offish about this, I just don't see
why this co-community needs to exist in lock-step with GDB.  As I said
in a previous reply, there are many, many build dependencies required to
build GDB beyond what is stored in the current CVS.

I am just trying to understand the force of history here.

Cheers,

Phil

Re: GIT and CVS

[Alfred M. Szmidt]

   >> So why are we still on CVS?  I'm not a release manager, so I do not have
   >
   > Because the complications associated with having many projects in the same 
   > repository are a lot of work to disentangle, and it is a lot of work to do 
   > the conversion (including all the infrastructure scripts, user 
   > instructions etc.) for any one project.
   >
   > I think binutils+gdb is the right unit to aim for getting into a separate 
   > repository, as discussed in 
   > <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.

   Ok, thanks for your response.  Beyond the reason why they were in
   the same repository for how many years, why do they still have to
   be?

Joseph mentioned other reasons as well, it isn't just because they
have been in a single tree for many years.  One other thing worth
mentioning is that unified source builds are immensly useful.

   I hack on GDB, and I really don't hack on much else.  This is not
   to diminish other projects, I just don't hack on them.  While other
   modules represented by other projects are important, I am trying to
   understand the reason why this is a blocker?  Building GDB requires
   a lot of dependencies outside of what is provided in the
   repository.

GDB only requires a normal POSIX system to compile.

   > ChangeLogs are very useful whatever the version control system;
   > it's routine to import snapshots from one system into another and
   > the ChangeLogs are readily available to see what source version
   > you actually have there.  ChangeLogs are convenient to grep and
   > much less I/O intensive than git operations are (especially when
   > your checkout is on NFS).

You can also fix ChangeLog entries after the fact, which is not
possible with git's commit messages.

   I nearly decided to delete that line from the email as I did not
   want to dilute the arguments.  I wrote the ChangeLog parser for
   Eclipse as I found ChangeLogs tiresome to write when history
   basically replaced it.  I must admit, even when I hack on emacs, it
   is still a pain.  I'll continue to do it, if people find it useful.
   However, git log is very, highly configurable.  The options are
   very broad.  And, as you can generate a git log from a local
   repository, the NFS thing should not be too difficult to overcome?

Could you explain how `git log' replaces ChangeLog? It doesn't do much
more than what `cvs log' does, so you still need to write which
function/variable was modified, and git log doesn't do that as far as
I know (it only lists which files, and how many lines where
added/delete which isn't very useful).

Re: GIT and CVS

[Jan Kratochvil]

On Thu, 13 Oct 2011 23:43:20 +0200, Alfred M. Szmidt wrote:
> Could you explain how `git log' replaces ChangeLog? It doesn't do much
> more than what `cvs log' does, so you still need to write which
> function/variable was modified, and git log doesn't do that as far as
> I know (it only lists which files, and how many lines where
> added/delete which isn't very useful).

You have primarily `git annotate [revision]' which is like `cvs annotate' but
with the speed of GIT you can really use it.  You have also `git log -S [-p]'
where you can filter patches on specific text changes, it is also very fast.

Despite maintaining uncountable branches of GDB I never use ChangeLogs, I do
not understand what to look there for.


Regards,
Jan

Re: GIT and CVS

[Eli Zaretskii]

> Date: Thu, 13 Oct 2011 23:50:20 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: pmuldoon@redhat.com, joseph@codesourcery.com, gdb@sourceware.org
> 
> You have primarily `git annotate [revision]' which is like `cvs annotate' but
> with the speed of GIT you can really use it.

??? When did you last use "git annotate"? and on what project?  That
command is notoriously slow in git.  E.g., it takes a whopping 4.5
minutes to run on a particularly large and history-rich file in the
Emacs repository.  That's a lot of time to wait, too long for everyday
usage.  (I understand that having annotate slow was a deliberate
design decision, because git designer(s) consider that command
unnecessary.)

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 00:08:35 +0200, Eli Zaretskii wrote:
> ??? When did you last use "git annotate"? and on what project?

Depending on what I do sometimes ~10x a day during complicated GDB backports.


> That command is notoriously slow in git.  E.g., it takes a whopping 4.5
> minutes to run on a particularly large and history-rich file in the Emacs
> repository.

The most expensive source file in GDB looks to be dwarf2read.c: 0m8.930s

While it is 0m7.394s with CVS right now (1) I need to be online and (2) I have
a luck sourceware.org is accessible.  From my scheduled regression testing
runs often the server is overloaded/inaccessible. (1b) I am not aware how to
make CVS repository copy for local use (but there may be some tool).


Regards,
Jan

Re: GIT and CVS

[Alfred M. Szmidt]

   (1b) I am not aware how to make CVS repository copy for local use
   (but there may be some tool).

It is just a matter of rsyncing the CVSROOT locally... Something like,

rsync --archive --delete --compress --progress \
      --exclude '#cvs.*' --exclude 'CVSROOT/config' \
      --exclude 'CVSROOT/history' --exclude 'CVSROOT/updatelog' \
      rsync://sources.redhat.com/gdb-cvs /com/cvs/gdb

And in your checkout to update the CVS/Root files:

for x in $(find . -name Root); do echo /com/gdb > $x; done

Re: GIT and CVS

[Alfred M. Szmidt]

   (1b) I am not aware how to make CVS repository copy for local use
   (but there may be some tool).

It is just a matter of rsyncing the CVSROOT locally... Something like,

rsync --archive --delete --compress --progress \
      --exclude '#cvs.*' --exclude 'CVSROOT/config' \
      --exclude 'CVSROOT/history' --exclude 'CVSROOT/updatelog' \
      rsync://sources.redhat.com/src-cvs /com/cvs/src

And in your checkout to update the CVS/Root files:

for x in $(find . -name Root); do echo /com/src > $x; done

Might work.

Re: GIT and CVS

[Eli Zaretskii]

> Date: Fri, 14 Oct 2011 00:24:41 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: ams@gnu.org, pmuldoon@redhat.com, joseph@codesourcery.com,
>         gdb@sourceware.org
> 
> On Fri, 14 Oct 2011 00:08:35 +0200, Eli Zaretskii wrote:
> > ??? When did you last use "git annotate"? and on what project?
> 
> Depending on what I do sometimes ~10x a day during complicated GDB backports.
> 
> 
> > That command is notoriously slow in git.  E.g., it takes a whopping 4.5
> > minutes to run on a particularly large and history-rich file in the Emacs
> > repository.
> 
> The most expensive source file in GDB looks to be dwarf2read.c: 0m8.930s

On fencepost.gnu.org, I get 18 to 20 seconds on that file.

I guess this also depends on the number of revision that the project
has.  GDB has 36544 (if my git command was correct ;-); Emacs has
106K.  And the file I was talking about, xdisp.c, has 1592 revisions
in its history, not 573 as dwarf2read.c.

So this problem is probably still in GDB's future.  But it is real
nonetheless.

Re: GIT and CVS

[Alfred M. Szmidt]

   > Could you explain how `git log' replaces ChangeLog? It doesn't do
   > much more than what `cvs log' does, so you still need to write
   > which function/variable was modified, and git log doesn't do that
   > as far as I know (it only lists which files, and how many lines
   > where added/delete which isn't very useful).

   You have primarily `git annotate [revision]' which is like `cvs
   annotate' but with the speed of GIT you can really use it.  You
   have also `git log -S [-p]' where you can filter patches on
   specific text changes, it is also very fast.

While useful, they don't replace information of this type:

        * configure.ac (tic6x-*-*): Remove gdb from noconfigdirs.

You still have to store that information _somewhere_, be it in a file
or in the commit message.  I just don't see how annotate/log replaces
that here, maybe it should? I don't know, but entries like that are
super useful to trace history of things.


As a side node, Coreutils stores "ChangeLog entries" in the commit
message, and dumps it to disk when they make a release.  It seems to
work well for them.

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 00:19:17 +0200, Alfred M. Szmidt wrote:
> While useful, they don't replace information of this type:
> 
>         * configure.ac (tic6x-*-*): Remove gdb from noconfigdirs.

git log -p:
   tic6x-*-*)
-    noconfigdirs="$noconfigdirs gdb sim"
+    noconfigdirs="$noconfigdirs sim"

git annotate:
005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1022)  tic6x-*-*)
34dd72a9        (     qiyao     2011-08-14 12:28:15 +0000       1023)    noconfigdirs="$noconfigdirs sim"
005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1024)    ;;
->
git show 34dd72a9

What's wrong with it?  And if I search which commit changed it:
	git log -p -Sgdb configure.ac


> You still have to store that information _somewhere_, be it in a file
> or in the commit message.

Still there should be stored + shown the associated mail which completely
misses here and which is stored there by GIT.

Currently I have to always look up the associated mails with each CVS commit
to have the reasons and background of each patch; it is really a lose of
engineering time looking up all the mails by hand I have to do with CVS:
	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-upstream.patch;hb=f16
	->
	...
	FYI: implement new DWARF macro proposal
	http://sourceware.org/ml/gdb-patches/2011-07/msg00732.html
	http://sourceware.org/ml/gdb-cvs/2011-07/msg00212.html
	...
	[patch][python] Fix sigsegv when a printer fails to return a value and string_print is set.
	http://sourceware.org/ml/gdb-patches/2011-07/msg00719.html
	http://sourceware.org/ml/gdb-cvs/2011-07/msg00234.html
	...
	etc.


>   I just don't see how annotate/log replaces
> that here, maybe it should? I don't know, but entries like that are
> super useful to trace history of things.

When I was a newbie to GDB I would not see the reason why string "gdb" was
removed from variable "noconfigdirs".  I would like to find out the mail
submit/reasoning/approval.  I tried now but I failed to find the mail.

Contrary to it you can see the explanation of a commit in:
	http://git.kernel.org/?p=git/git.git;a=commit;h=d4e85a1afe0a3310a3c8336c2824775901cc27d7

It is true I would prefer URL / Message-ID for the mail thread, it is not
commonly there even with GIT.  There are some other patch management software
for such tracking.


Regards,
Jan

Re: GIT and CVS

[Alfred M. Szmidt]

   > While useful, they don't replace information of this type:
   > 
   >         * configure.ac (tic6x-*-*): Remove gdb from noconfigdirs.

   git log -p:
      tic6x-*-*)
   -    noconfigdirs="$noconfigdirs gdb sim"
   +    noconfigdirs="$noconfigdirs sim"


   git annotate:
   005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1022)  tic6x-*-*)
   34dd72a9        (     qiyao     2011-08-14 12:28:15 +0000       1023)    noconfigdirs="$noconfigdirs sim"
   005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1024)    ;;
   ->
   git show 34dd72a9

   What's wrong with it?  And if I search which commit changed it:
	   git log -p -Sgdb configure.ac

I think you missunderstood me, if I am looking at a bug I wish to
follow the changes done to something, usually a function.  While
log/annotate are useful to see what the tree looked like at some
point, it doesn't help me follow how something has changed over a time
period.  ChangeLog makes this trivial.

   > You still have to store that information _somewhere_, be it in a file
   > or in the commit message.

   Still there should be stored + shown the associated mail which completely
   misses here and which is stored there by GIT.

You could store the exact same information in the ChangeLog, git
doesn't solve what you put in the ChangeLog/commit message. 

2011-07-22  Jakub Jelinek  <jakub@redhat.com>

	URL: http://sourceware.org/ml/binutils-cvs/2011-07/msg00116.html
 
	* dwarf2.h (DW_AT_GNU_macros): New.
	(enum dwarf_macro_record_type): New enum.  Add DW_MACRO_GNU_*.

Or, with a fictious bug ID:

2011-07-26  Tom Tromey  <tromey@redhat.com>

        Implement new DWARF macro proposal.  (Bug#123456)

        URL: http://sourceware.org/ml/gdb-patches/2011-07/msg00732.html

	* symfile.h (struct dwarf2_debug_sections) <macro>: New field.
....

   >   I just don't see how annotate/log replaces that here, maybe it
   > should? I don't know, but entries like that are super useful to
   > trace history of things.

   When I was a newbie to GDB I would not see the reason why string
   "gdb" was removed from variable "noconfigdirs".  I would like to
   find out the mail submit/reasoning/approval.  I tried now but I
   failed to find the mail.

I agree, such information is useful.  Several projects have started
adding it as part of the ChangeLog entry; like the examples above.

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 01:37:03 +0200, Alfred M. Szmidt wrote:
>    > While useful, they don't replace information of this type:
>    > 
>    >         * configure.ac (tic6x-*-*): Remove gdb from noconfigdirs.
> 
>    git log -p:
>       tic6x-*-*)
>    -    noconfigdirs="$noconfigdirs gdb sim"
>    +    noconfigdirs="$noconfigdirs sim"
> 
>    git annotate:
>    005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1022)  tic6x-*-*)
>    34dd72a9        (     qiyao     2011-08-14 12:28:15 +0000       1023)    noconfigdirs="$noconfigdirs sim"
>    005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1024)    ;;
>    ->
>    git show 34dd72a9
[...]
> I think you missunderstood me, if I am looking at a bug I wish to
> follow the changes done to something, usually a function.  While
> log/annotate are useful to see what the tree looked like at some
> point,

Not just at some point.  The [revision] parameter there can go back in history
which is why I also put it here in the former mail:

git annotate configure.ac 34dd72a9^
005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1022)  tic6x-*-*)
fe571c9f        (Joseph Myers   2011-04-28 13:24:51 +0000       1023)    noconfigdirs="$noconfigdirs gdb sim"
005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1024)    ;;

It could be made more convenient but GIT provides IMO the best such
feature+performance so far to make it feasible.


> it doesn't help me follow how something has changed over a time
> period.  ChangeLog makes this trivial.

ChangeLog is not usable for tracking such changes as I cannot trust it wrt
mistakes of its text vs. the real source changes.  And also/primarily the word
description of the diff (*) there is too general.

(*) I do not understand why it makes sense to re-state by human what is already
    present in the diff itself.


> You could store the exact same information in the ChangeLog, git
> doesn't solve what you put in the ChangeLog/commit message. 

The problem with CVS is I need to access the server for anything.  Which is
either slow or temporarily overloaded/inaccessible or I am just offline.

I would need to have always up-to-date rsync copy for local access - do you
have?  It is just easier with GIT, and working even for projects where usually
the rsync access is not provided (but no other projects use CVS anymore).


> Or, with a fictious bug ID:
> 
> 2011-07-26  Tom Tromey  <tromey@redhat.com>
> 
>         Implement new DWARF macro proposal.  (Bug#123456)
> 
>         URL: http://sourceware.org/ml/gdb-patches/2011-07/msg00732.html
[...]
> I agree, such information is useful.  Several projects have started
> adding it as part of the ChangeLog entry; like the examples above.

Yes, that would be great.


Thanks,
Jan

Re: GIT and CVS

[Alfred M. Szmidt]

   > I think you missunderstood me, if I am looking at a bug I wish to
   > follow the changes done to something, usually a function.  While
   > log/annotate are useful to see what the tree looked like at some
   > point,

   Not just at some point.  The [revision] parameter there can go back
   in history which is why I also put it here in the former mail:

   git annotate configure.ac 34dd72a9^
   005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1022)  tic6x-*-*)
   fe571c9f        (Joseph Myers   2011-04-28 13:24:51 +0000       1023)    noconfigdirs="$noconfigdirs gdb sim"
   005efcbe        (Joseph Myers   2010-03-23 16:05:34 +0000       1024)    ;;

   It could be made more convenient but GIT provides IMO the best such
   feature+performance so far to make it feasible.

But this is still at one fixed point in time and requires me to figure
out which commit to look at.  How can I see all changes to tic6x-*-*
in this files, or on a per tree basis?

   > it doesn't help me follow how something has changed over a time
   > period.  ChangeLog makes this trivial.

   ChangeLog is not usable for tracking such changes as I cannot trust
   it wrt mistakes of its text vs. the real source changes.  And
   also/primarily the word description of the diff (*) there is too
   general.

If you cannot trust the ChangeLog entries, then that is a bug in the
review process.

   (*) I do not understand why it makes sense to re-state by human
       what is already present in the diff itself.

Scrolling through big diffs is not how I want to spend my time.  :-)

   > You could store the exact same information in the ChangeLog, git

   I would need to have always up-to-date rsync copy for local access
   - do you have?  It is just easier with GIT, and working even for
   projects where usually the rsync access is not provided (but no
   other projects use CVS anymore).

On some machines I do have, using the rsync script I mentioned before.
I don't find it easier using git, or any other tool.  But yes, the
project needs to make the CVSROOT accessible; which is the case with
the src/ tree.

Re: GIT and CVS

[Phil Muldoon]

ams@gnu.org (Alfred M. Szmidt) writes:

>    >> So why are we still on CVS?  I'm not a release manager, so I do not have
>    >
>    > Because the complications associated with having many projects in the same 
>    > repository are a lot of work to disentangle, and it is a lot of work to do 
>    > the conversion (including all the infrastructure scripts, user 
>    > instructions etc.) for any one project.
>    >
>    > I think binutils+gdb is the right unit to aim for getting into a separate 
>    > repository, as discussed in 
>    > <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.
>
>    Ok, thanks for your response.  Beyond the reason why they were in
>    the same repository for how many years, why do they still have to
>    be?
>
> Joseph mentioned other reasons as well, it isn't just because they
> have been in a single tree for many years.  One other thing worth
> mentioning is that unified source builds are immensly useful.

I'm not debating that a unified source is useful, of course it is.  I
personally build GDB on Fedora, and beyond what is in the tree, there
are many non-inclusive packages I have to find to build GDB.  Are your
experiences different on your build setup? What do you have to include
in your build environment, beyond what is included? I am genuinely
interested from a cross-building experiences on many/disparate
platforms?

>
>    I hack on GDB, and I really don't hack on much else.  This is not
>    to diminish other projects, I just don't hack on them.  While other
>    modules represented by other projects are important, I am trying to
>    understand the reason why this is a blocker?  Building GDB requires
>    a lot of dependencies outside of what is provided in the
>    repository.
>
> GDB only requires a normal POSIX system to compile.

I don't deny that.  But this is the difference between what is included
in the repository, which seems to be the thrust of the argument, over
which is included in pretty much every distro out there.  Given an X
distro system, can you build GDB without any other external
dependencies?  I think not.  If other dependencies can be managed
externally, why cannot  other internal dependencies?


>    > ChangeLogs are very useful whatever the version control system;
>    > it's routine to import snapshots from one system into another and
>    > the ChangeLogs are readily available to see what source version
>    > you actually have there.  ChangeLogs are convenient to grep and
>    > much less I/O intensive than git operations are (especially when
>    > your checkout is on NFS).
>
> You can also fix ChangeLog entries after the fact, which is not
> possible with git's commit messages.
>
>    I nearly decided to delete that line from the email as I did not
>    want to dilute the arguments.  I wrote the ChangeLog parser for
>    Eclipse as I found ChangeLogs tiresome to write when history
>    basically replaced it.  I must admit, even when I hack on emacs, it
>    is still a pain.  I'll continue to do it, if people find it useful.
>    However, git log is very, highly configurable.  The options are
>    very broad.  And, as you can generate a git log from a local
>    repository, the NFS thing should not be too difficult to overcome?
>
> Could you explain how `git log' replaces ChangeLog? It doesn't do much
> more than what `cvs log' does, so you still need to write which
> function/variable was modified, and git log doesn't do that as far as
> I know (it only lists which files, and how many lines where
> added/delete which isn't very useful).

Jan has covered this in detail.  Lets just divorce this argument for
now.  If we have to continue building ChangeLogs with GIT then so be
it.  I'm not against this.

Cheers,

Phil

Re: GIT and CVS

[Alfred M. Szmidt]

   I'm not debating that a unified source is useful, of course it is.
   I personally build GDB on Fedora, and beyond what is in the tree,
   there are many non-inclusive packages I have to find to build GDB.

Do you have examples?  I don't install any strange dependencies most
of the time...

   Jan has covered this in detail.  Lets just divorce this argument
   for now.  If we have to continue building ChangeLogs with GIT then
   so be it.  I'm not against this.

I'm just trying to understand how git replaces ChangeLog (which are
the exact same thing as commit messages).  I suspect there is some
grave misunderstanding in the discussion.

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 01:50:49 +0200, Alfred M. Szmidt wrote:
>    I'm not debating that a unified source is useful, of course it is.
>    I personally build GDB on Fedora, and beyond what is in the tree,
>    there are many non-inclusive packages I have to find to build GDB.
> 
> Do you have examples?  I don't install any strange dependencies most
> of the time...

To name those usually not present on the system:
flex bison expat-devel zlib-devel python-devel texinfo
for testsuite at least:
dejagnu gcc-gfortran gcc-java gcc-objc prelink fpc gcc-gnat glibc-static valgrind


> I'm just trying to understand how git replaces ChangeLog (which are
> the exact same thing as commit messages).  I suspect there is some
> grave misunderstanding in the discussion.

Yes, that's the point - I do not find ChangeLog entry a sufficient (or
relevant at all) replacement of the diff itself.  While looking for a bug
I cannot trust all the previous work had no mistakes.


Thanks,
Jan

Re: GIT and CVS

[Alfred M. Szmidt]

   On Fri, 14 Oct 2011 01:50:49 +0200, Alfred M. Szmidt wrote:
   >    I'm not debating that a unified source is useful, of course it is.
   >    I personally build GDB on Fedora, and beyond what is in the tree,
   >    there are many non-inclusive packages I have to find to build GDB.
   > 
   > Do you have examples?  I don't install any strange dependencies most
   > of the time...

   To name those usually not present on the system:
   flex bison expat-devel zlib-devel python-devel texinfo

Only required when having modified files that are used as input for
generation, I tend to make a tarball with freshly regenerated files
and push that to the host I wish to test.  So no need for any of that
on the build platform.

   for testsuite at least:
   dejagnu gcc-gfortran gcc-java gcc-objc prelink fpc gcc-gnat glibc-static valgrind

And tcl.  The testsuite is a bit awkward to get up at times, fully agree there.  

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 08:52:03 +0200, Alfred M. Szmidt wrote:
>    To name those usually not present on the system:
>    flex bison expat-devel zlib-devel python-devel texinfo
> 
> Only required when having modified files that are used as input for
> generation, I tend to make a tarball with freshly regenerated files
> and push that to the host I wish to test.  So no need for any of that
> on the build platform.

With GIT it is easier to use directly the repository.

Also one has to use GIT locally anyway, I have for example pending 40 GDB
branches here.  Having each in a separate directory would mean about 20GB of
disk space, moreover making cross-branch diffs terribly slow reading+comparing
many GBs of data.  I hope you do not recommend using CVS branches (I used
those...).  It is true I do not know SVN/BZR/etc. branching feasibility.

And when you commit GIT->CVS it took me for the last 12-parts patchser over an
hour, moreover making a mistake breaking the repository by forgotten files:
	http://sourceware.org/ml/gdb-patches/2011-10/msg00243.html
	Add forgotten gdb/dwarf2-frame-tailcall.c.
	Add forgotten gdb/dwarf2-frame-tailcall.h.
It could be one just `git merge' and `git push'.


>    for testsuite at least:
>    dejagnu gcc-gfortran gcc-java gcc-objc prelink fpc gcc-gnat glibc-static valgrind
> 
> And tcl.

(This is a dependency of dejagnu.)


Thanks,
Jan

Re: GIT and CVS

[Alfred M. Szmidt]

   >    To name those usually not present on the system:
   >    flex bison expat-devel zlib-devel python-devel texinfo
   > 
   > Only required when having modified files that are used as input for
   > generation, I tend to make a tarball with freshly regenerated files
   > and push that to the host I wish to test.  So no need for any of that
   > on the build platform.

   With GIT it is easier to use directly the repository.

git doesn't store timestamps, which requires often regeneration of
files for no particular reason. :( cvs is stilly quite silly there
too...


But I'm (atleast) not arguing for or against git, I frankly don't care
as long as emacs works.  I was only interested in how git as a tool
replaceses the need for commit messages (ChangeLog); which isn't the
case at all.  I use git on a daily basis, but I don't find it easier
to use than say cvs, bzr, svn or anything else.

Re: GIT and CVS

[Joseph S. Myers]

On Fri, 14 Oct 2011, Jan Kratochvil wrote:

> And when you commit GIT->CVS it took me for the last 12-parts patchser over an
> hour, moreover making a mistake breaking the repository by forgotten files:
> 	http://sourceware.org/ml/gdb-patches/2011-10/msg00243.html
> 	Add forgotten gdb/dwarf2-frame-tailcall.c.
> 	Add forgotten gdb/dwarf2-frame-tailcall.h.

I really don't think this is an argument for one version control system 
over another.  They all seem to make it far too easy to commit patches 
where you've accidentally failed to add new files to version control.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 17:38:37 +0200, Joseph S. Myers wrote:
> I really don't think this is an argument for one version control system 
> over another.  They all seem to make it far too easy to commit patches 
> where you've accidentally failed to add new files to version control.

The point was to ensure the same version control system is used both locally
and server-side.  Which requires dVCS.  Which excludes for example SVN (and
also CVS).

I had a fear CVS may be considered as a valid VCS.


Thanks,
Jan

Re: GIT and CVS

[Joseph S. Myers]

On Thu, 13 Oct 2011, Phil Muldoon wrote:

> "Joseph S. Myers" <joseph@codesourcery.com> writes:
> 
> > On Thu, 13 Oct 2011, Phil Muldoon wrote:
> >
> >> So why are we still on CVS?  I'm not a release manager, so I do not have
> >
> > Because the complications associated with having many projects in the same 
> > repository are a lot of work to disentangle, and it is a lot of work to do 
> > the conversion (including all the infrastructure scripts, user 
> > instructions etc.) for any one project.
> >
> > I think binutils+gdb is the right unit to aim for getting into a separate 
> > repository, as discussed in 
> > <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.
> 
> Ok, thanks for your response.  Beyond the reason why they were in the
> same repository for how many years, why do they still have to be?
> 
> I can understand that projects so closely involved need to be in
> lock-step in their release objectives, but with healthy communities for
> each project, do they need to be still?

I've given my arguments many times before in past threads.  In essence:

* normal operations (checkouts, updates, tagging etc.) should be done in 
the normal way for the relevant version control systems, and the 
non-transparency of various systems for grafting pieces from different 
repositories tends to rule those out;

* that a normal operation ("cvs update -d") doesn't work properly is one 
of the serious problems with the present system;

* commits affecting both BFD and its clients are normal operations.

So I think putting the BFD users together with BFD is right - but I think 
a separate master repository for the shared toplevel files is also right 
(with hooks in other repositories to check for attempts to commit changes 
to shared files - on the mainline - that aren't just merges from the 
separate master).  The alternative for toplevel is the DVCSly pure 
approach with all repositories equal and no one master, but I think that 
would work less well in practice.

> I think though, I am missing the point.  If GDB decides, on its own, to
> go with GIT, what happens to the other projects?  What are the outcomes?

Synchronizing BFD would be a great pain.  For the projects other than 
binutils, I think they could continue just fine if gdb+binutils moves out 
(though with more toplevel pain if proper procedures aren't set up for 
keeping toplevel in sync).

> I nearly decided to delete that line from the email as I did not want to
> dilute the arguments.  I wrote the ChangeLog parser for Eclipse as I found
> ChangeLogs tiresome to write when history basically replaced it.  I must
> admit, even when I hack on emacs, it is still a pain.  I'll continue to
> do it, if people find it useful.  However, git log is very, highly
> configurable.  The options are very broad.  And, as you can generate a
> git log from a local repository, the NFS thing should not be too
> difficult to overcome?

Even with local disk, git is much more I/O intensive.  I timed looking at 
logs from a glibc checkout on local disk:

$ time git log > /dev/null

real    0m18.324s
user    0m0.560s
sys     0m0.304s
$ time cat ChangeLog* > /dev/null

real    0m0.314s
user    0m0.000s
sys     0m0.012s

That's nearly 60 times slower.  And apart from I/O cost the point remains 
that it is useful to have this information in tarballs and ad hoc 
snapshots, separated from the version control system and possibly imported 
into another.  I'd be glad to *expand* ChangeLogs - add information about 
*why* changes were made to the existing *what* - and so make them more 
useful, but they are useful anyway.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GIT and CVS

[Jan Kratochvil]

On Thu, 13 Oct 2011 23:50:33 +0200, Joseph S. Myers wrote:
> Even with local disk, git is much more I/O intensive.  I timed looking at 
> logs from a glibc checkout on local disk:
> 
> $ time git log > /dev/null
> 
> real    0m18.324s
> user    0m0.560s
> sys     0m0.304s

$ time git log >/dev/null

real	0m0.374s
user	0m0.330s
sys	0m0.041s

You cannot count the first operation, before ./.git gets cached.  The first
read is deficiency of kernel filesystem, pre-read and/or no SSD on your system.


Regards,
Jan

Re: GIT and CVS

[Joseph S. Myers]

On Thu, 13 Oct 2011, Jan Kratochvil wrote:

> You cannot count the first operation, before ./.git gets cached.  The first
> read is deficiency of kernel filesystem, pre-read and/or no SSD on your system.

The whole point of my timings was to time uncached reads and compare them 
to uncached reads of ChangeLogs.  I'm considering the user looking at lots 
of different trees from time to time, not spending all their time in an 
FSF GDB tree where they might have .git cached.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GIT and CVS

[Eli Zaretskii]

> Date: Thu, 13 Oct 2011 23:59:28 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: Phil Muldoon <pmuldoon@redhat.com>, gdb@sourceware.org
> 
> On Thu, 13 Oct 2011 23:50:33 +0200, Joseph S. Myers wrote:
> > Even with local disk, git is much more I/O intensive.  I timed looking at 
> > logs from a glibc checkout on local disk:
> > 
> > $ time git log > /dev/null
> > 
> > real    0m18.324s
> > user    0m0.560s
> > sys     0m0.304s
> 
> $ time git log >/dev/null
> 
> real	0m0.374s
> user	0m0.330s
> sys	0m0.041s
> 
> You cannot count the first operation, before ./.git gets cached.  The first
> read is deficiency of kernel filesystem, pre-read and/or no SSD on your system.

These comparisons are meaningless.  Logs are meant to be read by
humans, so the number of seconds it takes to dump all the log entries
to the null device is not an interesting measure of any practical
importance.

More to the point: ChangeLog files can be generated from a VCS log
when a release is tarred.  They can also be generated when a developer
wants a convenient file to look at with usual tools.  So whether or
not to keep the ChangeLog files is not the issue.  The issue is how to
save the committers the need to compose 2 different logs, one for the
commit, the other for the ChangeLog.  This issue should be resolved by
the VCS front end in use, like Emacs or whatever people use.  When
such solutions exist, it is no longer an important issue whether to
keep ChangeLog's in the repo or generate them as needed.

Re: GIT and CVS

[Joel Brobecker]

> The issue is how to
> save the committers the need to compose 2 different logs, one for the
> commit, the other for the ChangeLog.  This issue should be resolved by
> the VCS front end in use, like Emacs or whatever people use.  When
> such solutions exist, it is no longer an important issue whether to
> keep ChangeLog's in the repo or generate them as needed.

One problem that you are not mentioning is the fact that the ChangeLog
causes a never-ending stream of conflicts when applying patches. This
is because of how things are setup: We keep modifying the file at
the same place. ChangeLogs were interesting at a time when VCS where
limited, but we've abolished them at AdaCore ever since we moved our
GDB development to Git. The cost of maintaining them versus the actual
benefits was just too high.

-- 
Joel

Re: GIT and CVS

[Eli Zaretskii]

> Date: Thu, 13 Oct 2011 22:02:45 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, joseph@codesourcery.com,
> 	pmuldoon@redhat.com, gdb@sourceware.org
> 
> One problem that you are not mentioning is the fact that the ChangeLog
> causes a never-ending stream of conflicts when applying patches.

This problem has been solved quite some time ago, both in git (where
you have git-merge-changelog driver), and in bzr (where you have the
changelog_merge plugin, now distributed as part of core bzr).  I use
the latter, and didn't have a single ChangeLog conflict in many
months.

Re: GIT and CVS

[Phil Muldoon]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Thu, 13 Oct 2011, Phil Muldoon wrote:
>
>> "Joseph S. Myers" <joseph@codesourcery.com> writes:
>> 
>> > On Thu, 13 Oct 2011, Phil Muldoon wrote:
>> >
>> >> So why are we still on CVS?  I'm not a release manager, so I do not have
>> >
>> > Because the complications associated with having many projects in the same 
>> > repository are a lot of work to disentangle, and it is a lot of work to do 
>> > the conversion (including all the infrastructure scripts, user 
>> > instructions etc.) for any one project.
>> >
>> > I think binutils+gdb is the right unit to aim for getting into a separate 
>> > repository, as discussed in 
>> > <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.
>> 
>> Ok, thanks for your response.  Beyond the reason why they were in the
>> same repository for how many years, why do they still have to be?
>> 
>> I can understand that projects so closely involved need to be in
>> lock-step in their release objectives, but with healthy communities for
>> each project, do they need to be still?
>
> I've given my arguments many times before in past threads.  In essence:
>
> * normal operations (checkouts, updates, tagging etc.) should be done in 
> the normal way for the relevant version control systems, and the 
> non-transparency of various systems for grafting pieces from different 
> repositories tends to rule those out;

I agree on the branching, but I do not understand why GDB has to be
tagged/branched in tandem with other projects.  We survive OK with the
disparate GCC versions, as well as GLIBC and other close dependencies.


> * that a normal operation ("cvs update -d") doesn't work properly is one 
> of the serious problems with the present system;

This really catches a lot of newbies out, myself included.

>
> * commits affecting both BFD and its clients are normal operations.
>
> So I think putting the BFD users together with BFD is right - but I think 
> a separate master repository for the shared toplevel files is also right 
> (with hooks in other repositories to check for attempts to commit changes 
> to shared files - on the mainline - that aren't just merges from the 
> separate master).  The alternative for toplevel is the DVCSly pure 
> approach with all repositories equal and no one master, but I think that 
> would work less well in practice.

BFD is an important part of the GDB setup, no doubt it is.  But has
anyone (myself included), talked to the community about it?  Is there
any reason why BFD cannot be an external dependency?  GCC, as an
external dependency has far more radical design shifts, I think, than
BFD, and we cope just fine.


>> I think though, I am missing the point.  If GDB decides, on its own, to
>> go with GIT, what happens to the other projects?  What are the outcomes?
>
> Synchronizing BFD would be a great pain.  For the projects other than 
> binutils, I think they could continue just fine if gdb+binutils moves out 
> (though with more toplevel pain if proper procedures aren't set up for 
> keeping toplevel in sync).

I think really, we need to understand the relationship with BFD more
deeply.  If we are such in lock-step, then I agree a dual effort should
be undertaken.  I'm not sure I truly understand why this dependency has
to be managed internally, over every other dependency that GDB has to
cope with to be built.

>> I nearly decided to delete that line from the email as I did not want to
>> dilute the arguments.  I wrote the ChangeLog parser for Eclipse as I found
>> ChangeLogs tiresome to write when history basically replaced it.  I must
>> admit, even when I hack on emacs, it is still a pain.  I'll continue to
>> do it, if people find it useful.  However, git log is very, highly
>> configurable.  The options are very broad.  And, as you can generate a
>> git log from a local repository, the NFS thing should not be too
>> difficult to overcome?
>
> Even with local disk, git is much more I/O intensive.  I timed looking at 
> logs from a glibc checkout on local disk:
>
> $ time git log > /dev/null
>
> real    0m18.324s
> user    0m0.560s
> sys     0m0.304s
> $ time cat ChangeLog* > /dev/null
>
> real    0m0.314s
> user    0m0.000s
> sys     0m0.012s

From a metric point of view, yes your numbers point to your argument.
But 18 seconds in the real world? How do those numbers compare with CVS?
I think I want to divorce the argument with ChangeLogs.  That was
something, I regret, putting in.  If we have to put ChangeLogs with GIT
so be it, I can live with that.

>
> That's nearly 60 times slower.  And apart from I/O cost the point remains 
> that it is useful to have this information in tarballs and ad hoc 
> snapshots, separated from the version control system and possibly imported 
> into another.  I'd be glad to *expand* ChangeLogs - add information about 
> *why* changes were made to the existing *what* - and so make them more 
> useful, but they are useful anyway.

If we have to continue ChangeLogs, so be it.  I am willing to make that
concession.

Cheers,

Phil

Re: GIT and CVS

[Joseph S. Myers]

On Fri, 14 Oct 2011, Phil Muldoon wrote:

> > * normal operations (checkouts, updates, tagging etc.) should be done in 
> > the normal way for the relevant version control systems, and the 
> > non-transparency of various systems for grafting pieces from different 
> > repositories tends to rule those out;
> 
> I agree on the branching, but I do not understand why GDB has to be
> tagged/branched in tandem with other projects.  We survive OK with the
> disparate GCC versions, as well as GLIBC and other close dependencies.

I'm not saying "in tandem".  I'm saying "in the normal way".  That is, a 
normal "git tag" should tag BFD, libiberty etc. along with GDB, no other 
special operations needed, pushing the tag should also be done in the 
normal way, and so on.

> BFD is an important part of the GDB setup, no doubt it is.  But has
> anyone (myself included), talked to the community about it?  Is there
> any reason why BFD cannot be an external dependency?  GCC, as an
> external dependency has far more radical design shifts, I think, than
> BFD, and we cope just fine.

BFD, by design, does not have a stable ABI or API and is closely tied to 
its clients.  The same applies to libiberty (in principle anyway; in 
practice it may be more stable than BFD so you have more chance of a 
different libiberty version working with a libiberty client).

On the other hand, I'd quite like to see readline not go in the 
gdb+binutils repository; that ought to be considered an external 
dependency that you can drop in to the source tree yourself if you want to 
build it that way.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 01:56:06 +0200, Joseph S. Myers wrote:
> On the other hand, I'd quite like to see readline not go in the 
> gdb+binutils repository; that ought to be considered an external 
> dependency that you can drop in to the source tree yourself if you want to 
> build it that way.

There are still too many GDB-specific fixes+workarounds in src/readline/ to
make such unbundling useful.


Thanks,
Jan

Re: GIT and CVS

[Eli Zaretskii]

> From: Phil Muldoon <pmuldoon@redhat.com>
> Date: Thu, 13 Oct 2011 20:37:22 +0100
> 
> GIT is, I think, available everywhere, has a CVS interface, and is
> far, far quicker than CVS.

Git is available on GNU/Linux, which is a lot, but it ain't
"everywhere".

My main development machines run MS-Windows.  Git sucks on MS-Windows
(I don't like it much on GNU/Linux, either).  If we are to switch to
git, it'll probably make me much less active as a member of the GDB
project.

If we are going to switch to a dVCS, git is not the only choice.  I
like bzr better; bzr is a GNU project, unlike git.

Re: GIT and CVS

[Phil Muldoon]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Phil Muldoon <pmuldoon@redhat.com>
>> Date: Thu, 13 Oct 2011 20:37:22 +0100
>> 
>> GIT is, I think, available everywhere, has a CVS interface, and is
>> far, far quicker than CVS.
>
> Git is available on GNU/Linux, which is a lot, but it ain't
> "everywhere".

I guess we have to quantify the development platforms for GDB.  This is
different from the deployment platforms.  On which platforms do
developers develop on GDB? Is GIT available there? Is there a platform
where people contribute where GIT is not available?  I hope to find that
out.

> My main development machines run MS-Windows.  Git sucks on MS-Windows

In which way, how does it differ from GNU/Linux * Distros? Do you have
the CVS add-on to git on MS-Windows? Are you running Cygwin? If it
sucks, is it a matter of requesting maintainer updates?

> (I don't like it much on GNU/Linux, either).  If we are to switch to
> git, it'll probably make me much less active as a member of the GDB
> project.

GIT offers a CVS extension to make this as transparent as possible.  Why
would that affect your contribution?

> If we are going to switch to a dVCS, git is not the only choice.  I
> like bzr better; bzr is a GNU project, unlike git.

Given your question above, does bzr fulfill the roles any better than
GIT?

Cheers,

Phil

Re: GIT and CVS

[Eli Zaretskii]

> From: Phil Muldoon <pmuldoon@redhat.com>
> Cc: gdb@sourceware.org
> Date: Fri, 14 Oct 2011 00:20:34 +0100
> 
> > My main development machines run MS-Windows.  Git sucks on MS-Windows
> 
> In which way, how does it differ from GNU/Linux * Distros?

It's slow, and it requires MSYS, a fork of Cygwin that comes with its
own set of incompatible binaries for Bash, Coreutils, etc.  This
complicates your system setup if you already have Cygwin or native
MinGW environments.

> Do you have the CVS add-on to git on MS-Windows?

Sorry, I don't understand the question.  Why would I need this on the
client machine?

> Are you running Cygwin?

No.  I use native MinGW tools.

> If it sucks, is it a matter of requesting maintainer updates?

AFAIK, there are no plans to abandon MSYS as the platform for porting
git to Windows, and given the fact that git is maintained by Linux
kernel guys, I cannot expect any sympathy from then to supporting
Windows.

> > (I don't like it much on GNU/Linux, either).  If we are to switch to
> > git, it'll probably make me much less active as a member of the GDB
> > project.
> 
> GIT offers a CVS extension to make this as transparent as possible.  Why
> would that affect your contribution?

Because I don't want to be left behind: if GDB switches to a dVCS, I'd
like to use a dVCS, too.  The ease of local commits, the high
probability of conflict-free merges, the convenience of easily doing a
local branch, shelve and unshelve pending changes -- all those make my
life quality better, and I don't want to be a second-grade citizen
among GDB developers.

> > If we are going to switch to a dVCS, git is not the only choice.  I
> > like bzr better; bzr is a GNU project, unlike git.
> 
> Given your question above, does bzr fulfill the roles any better than
> GIT?

Yes, definitely.  For starters, it works on Posix and Windows
platforms alike.  Emacs uses bzr as its VCS for the last 2 years or
so.

Re: GIT and CVS

[Mark Kettenis]

> Date: Fri, 14 Oct 2011 10:13:31 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > > If we are going to switch to a dVCS, git is not the only choice.  I
> > > like bzr better; bzr is a GNU project, unlike git.
> > 
> > Given your question above, does bzr fulfill the roles any better than
> > GIT?
> 
> Yes, definitely.  For starters, it works on Posix and Windows
> platforms alike.  Emacs uses bzr as its VCS for the last 2 years or
> so.

I'm a git hater.  And the reason I hate GIT is because of the
development model it enforces.  It doesn't match the way I work.  My
workflow looks more or less as follows:

$ cvs update
(make some changes)
...
(come back a couple of days later)
$ cvs update
(merge conflicts, make some more changes)
...
$ cvs update
(test changes, write changelog, send diff for review)
...
$ cvs update
(test changes again, fixup changelog)
$ cvs commit

With lots of "cvs diff" invocations in between to check my changes and
remind myself what I'm working on.

I've used SVN, Mercurial and all of those VCSes have commands that are
close enough to CVS that they've allowed me to keep the same workflow
and didn't require me to look at their documentation for every command
I run.  With GIT there's several additional commands I have to run,
and I have to commit half-finished work, which I can't bring myself to
do.  (I've tried git stash, but it didn't seem to support my
development style, at least "unstashing" didn't "just work" when I did
a git fetch in between).

How does bzr compare here?  Is it close enough to CVS that there is a
1:1 mapping of commands with perhaps an additional command to "push"
changes upstream?

Re: GIT and CVS

[Eli Zaretskii]

> Date: Fri, 14 Oct 2011 12:22:53 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: pmuldoon@redhat.com, gdb@sourceware.org
> 
> $ cvs update
> (make some changes)
> ...
> (come back a couple of days later)
> $ cvs update
> (merge conflicts, make some more changes)
> ...
> $ cvs update
> (test changes, write changelog, send diff for review)
> ...
> $ cvs update
> (test changes again, fixup changelog)
> $ cvs commit
> [...]
> How does bzr compare here?  Is it close enough to CVS that there is a
> 1:1 mapping of commands with perhaps an additional command to "push"
> changes upstream?

Yes.  With bzr, you can "bind" your local branch to the upstream
repository, which then makes the workflow in that branch very similar
to what you have in CVS.  E.g., your workflow above will be literally
the same, except that "cvs" should be replaced with "bzr" (bzr has an
"update" command, which in a bound branch behaves exactly like "cvs
up"), and merge conflicts are extremely rare, because bzr is much
smarter about merges (as are git and Mercurial).  There isn't even the
need to use "bzr push", because in a bound branch "bzr commit" will
automatically commit locally and push upstream within the same
transaction.

You don't need to commit unfinished work, because "bzr up" in a bound
branch automatically merges the changes from upstream with your local
changes.

So you retain your CVS-like workflow, and in addition get all the
benefits of a dVCS: cheap branching, smart merges, possibility of
local commits (if you are off line), possibility of temporarily
"shelving" changes aside and returning to them later, etc.  But you
use all these beneficial features if you want to, you aren't forced to
do it.

Bzr on GNU/Linux is slower than git (any VCS is slower than git on
GNU/Linux), but I find it fast enough to not be an annoyance in
day-to-day work.

RE: GIT and CVS

[Li, Rongsheng]

Anyone remember how to unbscribe this ?

Thanks

Ken 

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Eli Zaretskii
Sent: Friday, October 14, 2011 3:56 AM
To: Mark Kettenis
Cc: pmuldoon@redhat.com; gdb@sourceware.org
Subject: Re: GIT and CVS

> Date: Fri, 14 Oct 2011 12:22:53 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: pmuldoon@redhat.com, gdb@sourceware.org
> 
> $ cvs update
> (make some changes)
> ...
> (come back a couple of days later)
> $ cvs update
> (merge conflicts, make some more changes) ...
> $ cvs update
> (test changes, write changelog, send diff for review) ...
> $ cvs update
> (test changes again, fixup changelog)
> $ cvs commit
> [...]
> How does bzr compare here?  Is it close enough to CVS that there is a
> 1:1 mapping of commands with perhaps an additional command to "push"
> changes upstream?

Yes.  With bzr, you can "bind" your local branch to the upstream repository, which then makes the workflow in that branch very similar to what you have in CVS.  E.g., your workflow above will be literally the same, except that "cvs" should be replaced with "bzr" (bzr has an "update" command, which in a bound branch behaves exactly like "cvs up"), and merge conflicts are extremely rare, because bzr is much smarter about merges (as are git and Mercurial).  There isn't even the need to use "bzr push", because in a bound branch "bzr commit" will automatically commit locally and push upstream within the same transaction.

You don't need to commit unfinished work, because "bzr up" in a bound branch automatically merges the changes from upstream with your local changes.

So you retain your CVS-like workflow, and in addition get all the benefits of a dVCS: cheap branching, smart merges, possibility of local commits (if you are off line), possibility of temporarily "shelving" changes aside and returning to them later, etc.  But you use all these beneficial features if you want to, you aren't forced to do it.

Bzr on GNU/Linux is slower than git (any VCS is slower than git on GNU/Linux), but I find it fast enough to not be an annoyance in day-to-day work.

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 12:22:53 +0200, Mark Kettenis wrote:
> $ cvs update
> (test changes, write changelog, send diff for review)
[...]
> With lots of "cvs diff" invocations in between to check my changes and
> remind myself what I'm working on.

Replace `cvs update' by: git stash; git pull; git stash pop
Replace `cvs diff' by: git diff HEAD
(not sure if the latter is needed but IMO it simplifies some assumptions)


> and I have to commit half-finished work,

You don't have to.


> (I've tried git stash, but it didn't seem to support my
> development style, at least "unstashing" didn't "just work" when I did
> a git fetch in between).

I do so sometimes myself, it works.

BTW you are right this style is not native to GIT, you should be on branch.


Regards,
Jan

Re: GIT and CVS

[Jonas Maebe]

On 14 Oct 2011, at 14:53, Jan Kratochvil wrote:

> On Fri, 14 Oct 2011 12:22:53 +0200, Mark Kettenis wrote:
>> (I've tried git stash, but it didn't seem to support my
>> development style, at least "unstashing" didn't "just work" when I  
>> did
>> a git fetch in between).
>
> I do so sometimes myself, it works.

I believe some older git versions refused to "git stash pop" if there  
was any conflict between the stashed changes and the new source code  
(I remember struggling with that myself the first time I tried git).  
Current git versions will however apply the stash in case of conflicts  
and mark those conflicts. The only thing it does now in case of  
conflicts is not drop the original stash (i.e., "git stash pop"  
behaves like a "git stash apply") so that you can easily apply it  
again on a clean copy should you somehow mess up during conflict  
resolution.


Jonas

Re: GIT and CVS

[Eli Zaretskii]

> Date: Fri, 14 Oct 2011 14:53:56 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: eliz@gnu.org, pmuldoon@redhat.com, gdb@sourceware.org
> 
> On Fri, 14 Oct 2011 12:22:53 +0200, Mark Kettenis wrote:
> > $ cvs update
> > (test changes, write changelog, send diff for review)
> [...]
> > With lots of "cvs diff" invocations in between to check my changes and
> > remind myself what I'm working on.
> 
> Replace `cvs update' by: git stash; git pull; git stash pop

But with bzr, you just say "bzr update" and that's it.

> Replace `cvs diff' by: git diff HEAD

But with bzr, you just say "bzr diff".

> (not sure if the latter is needed but IMO it simplifies some assumptions)

It is indeed one of my problems with git that I'm never sure what will
happen if I omit certain arguments that are supposed to be the
default.  But I always thought that was because I don't use git
enough.  However, if people like you, who do it all the time, are
still uncertain, then I guess it is something to consider when
selecting a VCS.

> > and I have to commit half-finished work,
> 
> You don't have to.

You mean, you can pull or merge when you have uncommitted changes?

> BTW you are right this style is not native to GIT, you should be on branch.

One problem with git is that too many things are not "right", and you
are punished if you like them.  I don't like software that imposes
ideology on me.

I do use local branches, but I don't like a tool that makes it very
hard not to work from a local branch.

Re: GIT and CVS

[Jan Kratochvil]

On Fri, 14 Oct 2011 16:25:49 +0200, Eli Zaretskii wrote:
> It is indeed one of my problems with git that I'm never sure what will
> happen if I omit certain arguments that are supposed to be the
> default.  But I always thought that was because I don't use git
> enough.  However, if people like you, who do it all the time, are
> still uncertain, then I guess it is something to consider when
> selecting a VCS.

This all comes from that GIT has between the commit state and workdir state
also index state.  I do not use the index so by "HEAD" I ignore the index
state and shortcut the workdir<->commit path.  Different usage scenarios may
benefit from the index, TIAOMWTDI.


> > > and I have to commit half-finished work,
> > 
> > You don't have to.
> 
> You mean, you can pull or merge when you have uncommitted changes?

They are stashed.  But in fact stashes are just a different namespace of
branches.


Regards,
Jan

Re: GIT and CVS

[Phil Muldoon]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 14 Oct 2011 14:53:56 +0200
>> From: Jan Kratochvil <jan.kratochvil@redhat.com>
>> Cc: eliz@gnu.org, pmuldoon@redhat.com, gdb@sourceware.org
>> 
>> On Fri, 14 Oct 2011 12:22:53 +0200, Mark Kettenis wrote:
>> > $ cvs update
>> > (test changes, write changelog, send diff for review)
>> [...]
>> > With lots of "cvs diff" invocations in between to check my changes and
>> > remind myself what I'm working on.
>> 
>> Replace `cvs update' by: git stash; git pull; git stash pop
>
> But with bzr, you just say "bzr update" and that's it.
>
>> Replace `cvs diff' by: git diff HEAD
>
> But with bzr, you just say "bzr diff".

If you have your git config setup right, you can use "git pull" to fetch
and merge changes in, and "git diff" to get a diff. In fact you can
configure GIT in multiple variations.  I think that is the strength of
GIT.  It allows you to use the tool your way, not necessarily how GIT
thinks you should.  That being said, it gives you enough rope, but then
again, so does CVS.

>
>> (not sure if the latter is needed but IMO it simplifies some assumptions)
>
> It is indeed one of my problems with git that I'm never sure what will
> happen if I omit certain arguments that are supposed to be the
> default.  But I always thought that was because I don't use git
> enough.  However, if people like you, who do it all the time, are
> still uncertain, then I guess it is something to consider when
> selecting a VCS.
>
>> > and I have to commit half-finished work,
>> 
>> You don't have to.
>
> You mean, you can pull or merge when you have uncommitted changes?

git pull

or

git fetch/git merge

If a conflict arises you have to git stash, then do above, then git
stash pop. Or you can just commit your changes locally.  The choice is
yours.

This is not how things are right now with CVS, but those steps are not
onerous.

Cheers,

Phil

Re: GIT and CVS

[Eli Zaretskii]

> From: Phil Muldoon <pmuldoon@redhat.com>
> Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, mark.kettenis@xs4all.nl,
>         gdb@sourceware.org
> Date: Fri, 14 Oct 2011 16:05:37 +0100
> 
> > You mean, you can pull or merge when you have uncommitted changes?
> 
> git pull
> 
> or
> 
> git fetch/git merge
> 
> If a conflict arises you have to git stash, then do above, then git
> stash pop. Or you can just commit your changes locally.  The choice is
> yours.

With bzr, I have a better choice: resolve the conflicts, and that's
it.  Just like with CVS.  So I think for Mark it would be much easier
to adapt.  Not that I fool myself that I will be able to convince the
others to adopt bzr...

> This is not how things are right now with CVS, but those steps are not
> onerous.

They might well be for someone who is a newcomer to git.  The user
documentation is not exactly favorable to newbies, so you are at the
mercy of tutorials out there on the net, whose quality and accuracy
are questionable, especially with newer git versions making them
outdated quickly enough to cost you quite an amount of trial and
error.

Re: GIT and CVS

[Phil Muldoon]

Mark Kettenis <mark.kettenis@xs4all.nl> writes:

>> Date: Fri, 14 Oct 2011 10:13:31 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> > > If we are going to switch to a dVCS, git is not the only choice.  I
>> > > like bzr better; bzr is a GNU project, unlike git.
>> > 
>> > Given your question above, does bzr fulfill the roles any better than
>> > GIT?
>> 
>> Yes, definitely.  For starters, it works on Posix and Windows
>> platforms alike.  Emacs uses bzr as its VCS for the last 2 years or
>> so.
>
> I'm a git hater.  And the reason I hate GIT is because of the
> development model it enforces.  It doesn't match the way I work.  My
> workflow looks more or less as follows:
>
> $ cvs update
> (make some changes)

git pull will fetch and merge changes.

> ...
> (come back a couple of days later)
> $ cvs update
> (merge conflicts, make some more changes)
> ...

Same as above.

> $ cvs update
> (test changes, write changelog, send diff for review)
> ...

No different, if this is how you choose to use GIT.

> $ cvs update
> (test changes again, fixup changelog)

No difference.

> $ cvs commit

git commit

then

git push

> With lots of "cvs diff" invocations in between to check my changes and
> remind myself what I'm working on.

I think this is where GIT would benefit most.  This is something that
GIT, imo, does far faster, and far better than CVS.

> I've used SVN, Mercurial and all of those VCSes have commands that are
> close enough to CVS that they've allowed me to keep the same workflow
> and didn't require me to look at their documentation for every command
> I run. 

But I don't see how your workflow changes, at all.  You can use GIT with
a CVS-like workflow just fine.

>  With GIT there's several additional commands I have to run,
> and I have to commit half-finished work, which I can't bring myself to
> do.  (I've tried git stash, but it didn't seem to support my
> development style, at least "unstashing" didn't "just work" when I did
> a git fetch in between).

Nope, you don't have to commit half finished work at all.  Commit it if
you want, or just keep it local as with CVS.

> How does bzr compare here?  Is it close enough to CVS that there is a
> 1:1 mapping of commands with perhaps an additional command to "push"
> changes upstream?

I don't know.  My one brief experience with bzr while checking out emacs
was painfully slow.

Cheers,

Phil

Re: GIT and CVS

[Eli Zaretskii]

> From: Phil Muldoon <pmuldoon@redhat.com>
> Cc: eliz@gnu.org, gdb@sourceware.org
> Date: Fri, 14 Oct 2011 15:51:40 +0100
> 
> > $ cvs update
> > (make some changes)
> 
> git pull will fetch and merge changes.

Then why does the man page says it's "discouraged"?

       Warning: Running git pull (actually, the underlying git merge) with
       uncommitted changes is discouraged: while possible, it leaves you in a
       state that is hard to back out of in the case of a conflict.

That sounds like "don't do it".

> > $ cvs commit
> 
> git commit
> 
> then
> 
> git push

Bzr's "bzr commit" is simpler: just one command, no need to remember
to run 2 commands.

Let's face it: git usage frowns on centralized or star-shape
development patterns.  So git commands and "normal" workflows do not
lend themselves easily towards that.

> > With lots of "cvs diff" invocations in between to check my changes and
> > remind myself what I'm working on.
> 
> I think this is where GIT would benefit most.  This is something that
> GIT, imo, does far faster, and far better than CVS.

_Any_ dVCS will do much betetr here, because these operations are
entirely local, they don't need to hit the wire.

> My one brief experience with bzr while checking out emacs was
> painfully slow.

When was that, and how slow was "painfully slow"?

Re: GIT and CVS

[Jonas Maebe]

On 14 Oct 2011, at 17:04, Eli Zaretskii wrote:

> From: Phil Muldoon <pmuldoon@redhat.com>
> Cc: eliz@gnu.org, gdb@sourceware.org
> Date: Fri, 14 Oct 2011 15:51:40 +0100
> 
>> git pull will fetch and merge changes.
> 
> Then why does the man page says it's "discouraged"?
> 
>       Warning: Running git pull (actually, the underlying git merge) with
>       uncommitted changes is discouraged: while possible, it leaves you in a
>       state that is hard to back out of in the case of a conflict.
> 
> That sounds like "don't do it".

What they describe is the same behaviour you get when doing a cvs update on a dirty tree: in case there are conflicts, you don't have a copy anymore of your original patch against the version to which it cleanly applied. They discourage that because that can be annoying. In case of a git stash or branch (which in case of cvs would correspond to something like "cvs diff > preupdate.patch", optionally with a record of the current revisions of all files involved), you keep a clean copy of your patch in its original version for comparison purposes afterwards.


Jonas

Re: GIT and CVS

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Then why does the man page says it's "discouraged"?
>
>        Warning: Running git pull (actually, the underlying git merge) with
>        uncommitted changes is discouraged: while possible, it leaves you in a
>        state that is hard to back out of in the case of a conflict.

cvs doesn't warn you, but the effect is the same.

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: GIT and CVS

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> git commit
>> 
>> then
>> 
>> git push
>
> Bzr's "bzr commit" is simpler: just one command, no need to remember
> to run 2 commands.

bzr also needs push.

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: GIT and CVS

[Eli Zaretskii]

> From: Andreas Schwab <schwab@redhat.com>
> Cc: pmuldoon@redhat.com, mark.kettenis@xs4all.nl, gdb@sourceware.org
> Date: Fri, 14 Oct 2011 18:11:40 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> git commit
> >> 
> >> then
> >> 
> >> git push
> >
> > Bzr's "bzr commit" is simpler: just one command, no need to remember
> > to run 2 commands.
> 
> bzr also needs push.

Of course, it pushes.  It just does that automatically (in a bound
branch) when you say "commit".

Re: GIT and CVS

[Matt Rice]

On Fri, Oct 14, 2011 at 9:19 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Andreas Schwab <schwab@redhat.com>
>> Cc: pmuldoon@redhat.com, mark.kettenis@xs4all.nl, gdb@sourceware.org
>> Date: Fri, 14 Oct 2011 18:11:40 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> git commit
>> >>
>> >> then
>> >>
>> >> git push
>> >
>> > Bzr's "bzr commit" is simpler: just one command, no need to remember
>> > to run 2 commands.
>>
>> bzr also needs push.
>
> Of course, it pushes.  It just does that automatically (in a bound
> branch) when you say "commit".
>

then use a git->bzr bridge?

http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-git-projects.html

Re: GIT and CVS

[Eli Zaretskii]

> Date: Fri, 14 Oct 2011 09:59:03 -0700
> From: Matt Rice <ratmice@gmail.com>
> Cc: Andreas Schwab <schwab@redhat.com>, pmuldoon@redhat.com, mark.kettenis@xs4all.nl, 
> 	gdb@sourceware.org
> 
> On Fri, Oct 14, 2011 at 9:19 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Andreas Schwab <schwab@redhat.com>
> >> Cc: pmuldoon@redhat.com, mark.kettenis@xs4all.nl, gdb@sourceware.org
> >> Date: Fri, 14 Oct 2011 18:11:40 +0200
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> git commit
> >> >>
> >> >> then
> >> >>
> >> >> git push
> >> >
> >> > Bzr's "bzr commit" is simpler: just one command, no need to remember
> >> > to run 2 commands.
> >>
> >> bzr also needs push.
> >
> > Of course, it pushes.  It just does that automatically (in a bound
> > branch) when you say "commit".
> >
> 
> then use a git->bzr bridge?
> 
> http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-git-projects.html

I already have that.  That's how I track the git mirror of GDB.

Unfortunately, bzr-git does not yet support "push".  So if GDB would
switch to git, I'll be unable to commit changes.

Re: GIT and CVS

[Steinar Bang]

>>>>> Mark Kettenis <mark.kettenis@xs4all.nl>:

> I'm a git hater.  And the reason I hate GIT is because of the
> development model it enforces.  It doesn't match the way I work.  My
> workflow looks more or less as follows:

> $ cvs update
> (make some changes)

git pull
make some changes

(or better:
 git pull
 make some changes and commit them)

> ...
> (come back a couple of days later)
> $ cvs update
> (merge conflicts, make some more changes)

git stash
git pull
git stash pop
(fix merge conflicts with the stash pop, make some more changes)

(or better:
 a) git pull
    (fix merge conflicts, make more changes and commit them)
 b) git pull --rebase
    (fix merge conflicts, make more changes and commit them)

> ...
> $ cvs update
> (test changes, write changelog, send diff for review)

git stash
git pull
git stash pop
(test changes, write changelog, send diff for review)

(or better:
 a) git pull
    (test changes, write changelog, send diff for review)
 b) git pull --rebase
    (test changes, write changelog, send diff for review)

> ...
> $ cvs update
> (test changes again, fixup changelog)

git stash
git pull
git stash pop
(test changes again, fixup changelog, commit)

(or better:
 a) git pull
    (test changes again, fixup changelog, commit)
 b) git pull --rebase
    (test changes again, fixup changelog, commit)

> $ cvs commit

git push.

Note to the following: using "git stash" lets you avoid having commits
for your changes, but
 1. that gives more commands for updates
 2. having fine grained commits helps the git merge magic

So the git way is to have fine grained commits.  That works for me,
because that's the way I used to prefer to stage my CVS checkins.  And
when working with continous integration server, that was always a pain.

With git I can have that, and it's the "git push" that triggers the
build.

And if you use commits there are two ways you can "update":
 1. git pull
 2. git pull --rebase

"git pull" will merge your current changes with the upstream changes,
and they will become intermingled in the history.

"git pull --rebase" will update the workspace, and then re-apply all of
your commits to the rebase (giving them a new date).

I started out using git, doing "git pull --rebase" since this seemed
most familiar to me (I was used to CVS and then SVN).  But today I use a
different pattern: I use shortlived local feature branches, and make my
commits on them, and after they are merged into the tracking branch and
pushed, I can delete the feature branches.

Re: GIT and CVS

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Fri, 11 Nov 2011 21:47:43 +0100
> 
> >>>>> Mark Kettenis <mark.kettenis@xs4all.nl>:
> 
> > I'm a git hater.  And the reason I hate GIT is because of the
> > development model it enforces.  It doesn't match the way I work.  My
> > workflow looks more or less as follows:
> 
> > $ cvs update
> > (make some changes)
> > ...
> > (come back a couple of days later)
> > $ cvs update
> > (merge conflicts, make some more changes)
> > ...
> > $ cvs update
> > (test changes, write changelog, send diff for review)
> > ...
> > $ cvs update
> > (test changes again, fixup changelog)
> > $ cvs commit
>
> [git wokflow omitted]

Mark explicitly said he wanted to stick to his workflow.  Showing him
a completely different workflow, one that uses 2 additional commands,
whose semantics is non-trivial (e.g., the "rebase" part needs to be
well understood before you can use it safely, is not what was
requested.

Re: GIT and CVS

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Mark explicitly said he wanted to stick to his workflow. 

Even though it isn't the best workflow with the tool?  Many small
commits _is_ the best approach with git, because it prepares for clever
merging.

Many small commits gives nice `C-x v g' results in emacs (or for that
matter nice and relevant `C-x v l' results), even after merging right
and left.

(Also, speaking as an ex-CVS user I've actually wanted to do small
commits, with relevant comments.  But I have constrained myself to use
big commits, to avoid triggering too many builds on continous
integration servers.)

> Showing him a completely different workflow, one that uses 2
> additional commands, whose semantics is non-trivial (e.g., the
> "rebase" part needs to be well understood before you can use it
> safely,

I mentioned "rebase" because that's the thing that seems to give the
most familiar behaviour to many ex-CVS users (eg. myself).  I no longer
thing rebase is a good idea, so maybe I shouldn't have...?

> is not what was requested.

Then he could just use "git pull", instead of "cvs update" (as others
have suggested), and revert to
 git stash
 git pull
 git stash pop
if the pull touches a file that has been modified locally, and then
eventually "git push"(*).

That should be more or less identical to the cvs workflow.  At least I
fail to see the difference.

(*) I saw this discussed in a different place in the thread.  I do know
    the difference between a simple "git push" and "git push origin
    HEAD", but I will only spend time to explain it if anybody expresses
    interest...:-)

Re: GIT and CVS

[Joel Brobecker]

> Personally, I'll give a strong bias to Joel's opinions because, frankly,
> he has to deal with this issue far more than any other. 

Personally, I am very much in favor of moving to git.  But I shouldn't
have a bigger weight on the decision, because the release is only one
very small portion of the work that our VCS creates for everyone during
our everyday work.

IMO: discussions about which system is better are almost useless.
Nothing will happen until we have a plan. Discussions about what
the problems are are more useful, as someone motivated might be able
to craft a plan that can be accepted and then implemented.

-- 
Joel

Re: GIT and CVS

[Joseph S. Myers]

On Thu, 13 Oct 2011, Joel Brobecker wrote:

> IMO: discussions about which system is better are almost useless.
> Nothing will happen until we have a plan. Discussions about what
> the problems are are more useful, as someone motivated might be able
> to craft a plan that can be accepted and then implemented.

Indeed, we need a plan that deals with all the different bits of 
infrastructure and documentation needing updating.

I support a move to a DVCS, probably git, keeping ChangeLogs as-is, 
keeping binutils and GDB together but not the other pieces not listed in 
(a) and (b) in <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>, with the 
new repository having copies of the required shared toplevel files but not 
being the master for them (that being a separate repository if there is a 
single master at all), with the gdbtk bits preferably but not necessarily 
going in a separate repository or branch.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GIT and CVS

[André Pönitz]

On Thursday 13 October 2011 21:37:22 ext Phil Muldoon wrote:
> 
> At the risk of atomizing the poor horse, I want to refresh ideas and
> thoughts on this.  
> 
> First, I'll point out I am in favor of GIT.  Not because GIT has won me
> over heart-and-soul, but purely because I can work on GDB GIT offline.
> This is not an inconsiderable benefit.  I can create local check-ins,
> create branches, merge, cherry-pick all in the leisure of my own office,
> or garden, or airport ... without internet access.
> 
> So that is my bias laid out.

Not sure whether a mere gdb _user's_ input is asked for here, but as I
try to stay somewhat in touch with the code I am affected by the SCM 
system gdb uses, too. Only a little, but enough to care. 

So...

I personally don't _like_ git.

It just (subjectively...) happens to be best-of-breed right now, so it is 
what I use if I have a choice. For non-git based projects I often enough
create a local git 'mirror' for browsing, history walking etc. With gdb I find
myself almost exclusively using a clone of git://sourceware.org/git/gdb.git.

> So why are we still on CVS?  I'm not a release manager, so I do not have
> to do the difficult work of cutting branches, and all of the difficult
> work in making releases.  But what are the objections to GIT?
> Personally, I'll give a strong bias to Joel's opinions because, frankly,
> he has to deal with this issue far more than any other. 
> 
> GIT is, I think, available everywhere, has a CVS interface, and is
> far, far quicker than CVS.  Maybe with the stronger identity and
> information that comes with GIT logs we can finally retire
> ChangeLogs.
> 
> CVS has served very well over the years.  I, and many others, cut our
> teeth on it.  It's been a good system.  But beyond stability I
> don't see it keeping up with functionality of other repository systems.
> I find myself working on GIT 98% of the time, and the other 2% dealing
> with CVS on the final check-in.  Surely I can't be the only hacker that
> does this?  If the vast majority are in this work-flow, perhaps we
> should think about the pros and the cons again.  I have no ideas about
> the work-flows of my GDB hackers, and if, you know, we are all doing this
> then we should recognize the elephant in the room.  If not, then I will
> go happily into the (CVS) night, content on the validity of its use and
> utility.
> 
> So, what do you think?

After skipping the intermediate SVN step (which a lot of other projects had
and which probably would have been a decent solution for gdb for the period
2003-2010 or so, too) moving to git _now_ seems to be an excellent idea.

I have also the impression that most of the recent gdb improvements were
done by people using git and "ported" to CVS afterwards. Making the lifes
of active contributors easier by removing this extra step should benefit the 
project as a whole.

I've seen this suggestion has sparked quite some interest on the mailing
list in the meantime. I'd like to comment on a few comments.

* All ChangeLog related discussion is a red herring. One _could_ have a plain
text file called "ChangeLog" in a git repo without complications.

* "Git sucks on MS-Windows". Git is usable on Windows to a degree that projects
much bigger than gdb switched to it, after careful consideration of a lot of
alternatives, including commercial offerings. My main work currently is on a
smaller cross platform project about 3/4 the "total size" of gdb (including
bfd, libiberty,  etc) and this is certainly in a very usable state on Windows.

* The timing discussion revolves around use cases where git is slower, in
the single-digit or even fraction-of-a second range. The discussion, however, 
does not include any use cases reflecting workflows _enabled_ by that 
"slowness" that are not even remotely feasible in the CVS world. "git bisect"
comes to mind. Use it _once_ and you have set off a life time's worth of 
"wasting" half seconds on annotation. Not to mention the branching, 
merging and rebasing business. 


May I suggests a meritocratic approach to solve the problem, and simply let
the people who currently work on the code base choose the tools they want?

  git log @{"1 year ago"}..HEAD | grep ^Author: | sort | uniq -c | sort -n | tail -20

runs e.g. in "real 0m0.079, user 0m0.076s, sys 0m0.008" here, so at least 
in theory this could be a fairly quick decision. 

I understand this is unfair as it does not reflect the effort patch reviewers
have put into the project. Maybe mailing list activity can be incorporated in
the numbers. But I'd call it a starting point.

Andre'

Re: GIT and CVS

[Eli Zaretskii]

> From: André Pönitz <andre.poenitz@nokia.com>
> Date: Fri, 14 Oct 2011 14:35:59 +0200
> 
> * "Git sucks on MS-Windows". Git is usable on Windows

Git _is_ usable on Windows, but it still sucks.  It doesn't integrate
well with a native MinGW environment, I cannot easily invoke it from
the Emacs VC interface, etc.  It's inconvenient.

> * The timing discussion revolves around use cases where git is slower, in
> the single-digit or even fraction-of-a second range. The discussion, however, 
> does not include any use cases reflecting workflows _enabled_ by that 
> "slowness" that are not even remotely feasible in the CVS world. "git bisect"
> comes to mind. Use it _once_ and you have set off a life time's worth of 
> "wasting" half seconds on annotation. Not to mention the branching, 
> merging and rebasing business. 

It goes without saying that a modern dVCS is better than CVS in many
ways.  But switching to a dVCS does not necessarily mean git, there
are alternatives.  For example, bisecting is supported by bzr and
Mercurial as well.

So please don't make it sound like the only 2 choices are CVS and git.

Re: GIT and CVS

[Phil Muldoon]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: André Pönitz <andre.poenitz@nokia.com>
>> Date: Fri, 14 Oct 2011 14:35:59 +0200
>> 
>> * "Git sucks on MS-Windows". Git is usable on Windows
>
> Git _is_ usable on Windows, but it still sucks.  It doesn't integrate
> well with a native MinGW environment, I cannot easily invoke it from
> the Emacs VC interface, etc.  It's inconvenient.

I use emacs and git daily.  It would help if you could describe this.
How does it not integrate well with the MinGW environment? Is it a
matter of configuration, or some software limitation issue?
>
>> * The timing discussion revolves around use cases where git is slower, in
>> the single-digit or even fraction-of-a second range. The discussion, however, 
>> does not include any use cases reflecting workflows _enabled_ by that 
>> "slowness" that are not even remotely feasible in the CVS world. "git bisect"
>> comes to mind. Use it _once_ and you have set off a life time's worth of 
>> "wasting" half seconds on annotation. Not to mention the branching, 
>> merging and rebasing business. 
>
> It goes without saying that a modern dVCS is better than CVS in many
> ways.  But switching to a dVCS does not necessarily mean git, there
> are alternatives.  For example, bisecting is supported by bzr and
> Mercurial as well.
>
> So please don't make it sound like the only 2 choices are CVS and git.

Well the original topic was about CVS and GIT, so that should be
directed to me, over Andre.  But archer uses git, a lot of people
(unscientific I know) use the GDB git mirror.  So those are the options
that I constrained the conversation too.

Cheers,

Phil

Re: GIT and CVS

[Eli Zaretskii]

> From: Phil Muldoon <pmuldoon@redhat.com>
> Cc: André Pönitz <andre.poenitz@nokia.com>,
>         gdb@sourceware.org
> Date: Fri, 14 Oct 2011 16:01:38 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: André Pönitz <andre.poenitz@nokia.com>
> >> Date: Fri, 14 Oct 2011 14:35:59 +0200
> >> 
> >> * "Git sucks on MS-Windows". Git is usable on Windows
> >
> > Git _is_ usable on Windows, but it still sucks.  It doesn't integrate
> > well with a native MinGW environment, I cannot easily invoke it from
> > the Emacs VC interface, etc.  It's inconvenient.
> 
> I use emacs and git daily.  It would help if you could describe this.
> How does it not integrate well with the MinGW environment? Is it a
> matter of configuration, or some software limitation issue?

It's a matter of tinkering with your Emacs configuration and your
system configuration.

There's no native git port to Windows.  There's the Cygwin port, and
there's the port based on MSYS (MsysGit).  If your development
environment is Cygwin, or if you use MSYS tools for everyday work
anyway, then perhaps you already have Emacs set up for them (for
Cygwin, the best way is simply to use the Cygwin build of Emacs).  But
my development environment includes neither Cygwin nor MSYS, it is a
native w32 environment.  The native w32 ports of Posix tools I use are
incompatible with MSYS or Cygwin tools.  So for me, using git means to
have 2 segregated environments, or somehow be able to use MsysGit
without stumbling on the MSYS programs it brings with it.

The only easy way I found to do that is to use git from the MSYS
shell, and not have it on my normal PATH, which means I need either a
separate Emacs session, or give up the Emacs VC interface to git.

> Well the original topic was about CVS and GIT, so that should be
> directed to me, over Andre.  But archer uses git, a lot of people
> (unscientific I know) use the GDB git mirror.  So those are the options
> that I constrained the conversation too.

I use the git mirror as well, though the bzr-git plugin.  But I only
do that because there's no bzr mirror; if there were, I would use bzr
instead.

Re: GIT and CVS

[André Pönitz]

On Friday 14 October 2011 16:19:01 ext Eli Zaretskii wrote:
> [..] It goes without saying that a modern dVCS is better than CVS in many
> ways.  But switching to a dVCS does not necessarily mean git, there
> are alternatives.  For example, bisecting is supported by bzr and
> Mercurial as well.
> 
> So please don't make it sound like the only 2 choices are CVS and git.

You are right, there are more dVCS options. 

My restriction to git was however intentional, as this was the topic of the
thread and Phil's original question and also what the non-cvs-using gdb 
developers actually use. Moreover it's something I use, and feel sort of
comfortable with.

I don't think changing the direction into a generic "what VCS is best"
discussion would be helpful. At best, we would come up with the same
conclusion as everyone else in such discussions, namely that there is
no single best VCS system.

I think this is all about making the life of the people who actually write the 
code easier. Right now it looks like they are mostly comfortable with git.
Might not be the perfect choice in some people's opinion, but why care?
Even if they wanted to use IP over Avian Carriers because they _know_
it makes them more productive I'd see no reason to discuss packet loss 
rates ;-}

Don't let the perfect be the enemy of the good. Using git is so much of a 
step forward compared to CVS that I can't imagine _any_ difference between
git and other dVCSs to obliterate the gain of going from CVS to git.

Andre'

PS: Btw, during my "personal" switch to git I also found the need to type 
two commands instead of one rather annoying. I ended up with a handful 
shell functions like 'gp' for  "git stash; git pull --rebase; git stash pop".
Not sure whether this is good practice, but it certainly solved that "problem".

Re: GIT and CVS

[Phil Muldoon]

André Pönitz <andre.poenitz@nokia.com> writes:

> Not sure whether a mere gdb _user's_ input is asked for here, but as I
> try to stay somewhat in touch with the code I am affected by the SCM 
> system gdb uses, too. Only a little, but enough to care. 


It's asked for and welcomed.

> So...
>
> I personally don't _like_ git.


Right, I don't think it will any personality contests.  But without
doubt it is powerful tool.

> It just (subjectively...) happens to be best-of-breed right now, so it is 
> what I use if I have a choice. For non-git based projects I often enough
> create a local git 'mirror' for browsing, history walking etc. With gdb I find
> myself almost exclusively using a clone of git://sourceware.org/git/gdb.git.

I do too.


> I have also the impression that most of the recent gdb improvements were
> done by people using git and "ported" to CVS afterwards. Making the lifes
> of active contributors easier by removing this extra step should benefit the 
> project as a whole.

Right, and what I asked with this email was to get a picture of the
contributors and what their workflow was.  Is anyone using CVS on a
daily basis for active development.  We cannot go to the server and get
usage stats as each commit has to use CVS.

> * All ChangeLog related discussion is a red herring. One _could_ have a plain
> text file called "ChangeLog" in a git repo without complications.

I think mixing these two topics was wrong on my part
.  
> * "Git sucks on MS-Windows". Git is usable on Windows to a degree that projects
> much bigger than gdb switched to it, after careful consideration of a lot of
> alternatives, including commercial offerings. My main work currently is on a
> smaller cross platform project about 3/4 the "total size" of gdb (including
> bfd, libiberty,  etc) and this is certainly in a very usable state on Windows.

That's interesting, is there an active community around GIT there?

> * The timing discussion revolves around use cases where git is slower, in
> the single-digit or even fraction-of-a second range. The discussion, however, 
> does not include any use cases reflecting workflows _enabled_ by that 
> "slowness" that are not even remotely feasible in the CVS world. "git bisect"
> comes to mind. Use it _once_ and you have set off a life time's worth of 
> "wasting" half seconds on annotation. Not to mention the branching, 
> merging and rebasing business. 

The one workflow, to me, is cvs diffs.  Maybe it is because I am in the
UK but CVS diffs are just painfully slow.  And commits.  Sometimes
taking 10+ minutes to complete.

Cheers,

Phil

RE: GIT and CVS

[Paul_Koning]

The mail string subject is GIT vs CVS, but a lot of the discussion seems to be "replace CVS by something better" -- and the debate is on whether GIT is the right replacement or something else is.

For the most part, my opinion is that anything at all (other than SCCS) is a *massive* improvement on CVS, and getting rid of CVS is many years overdue.  So I support any way at all that this can happen.

All things being equal I like SVN, but I get the impression that this isn't the majority opinion (even though GCC uses it).  It certainly has a number of key attributes, such as atomicity and speed.

	paul

Re: GIT and CVS

[Ralf Corsepius]

On 10/14/2011 05:02 PM, Paul_Koning@Dell.com wrote:
> The mail string subject is GIT vs CVS, but a lot of the discussion seems to be "replace CVS by something better" -- and the debate is on whether GIT is the right replacement or something else is.

The debate should not be about GIT vs. CVS but about which
"VCS caters gdb's developers' needs"
and about which
"VCS caters the gdb project's technical needs"
best.

> For the most part, my opinion is that anything at all (other than SCCS) is a *massive* improvement on CVS,
Basically agreed, except that "everything comes at a price".

That said, though most VCSes have aspects where they are superior to 
CVS, I haven't seen any which didn't also introduce regressions.

> All things being equal I like SVN, but I get the impression that this isn't the majority opinion (even though GCC uses it).
Well, I feel, due to git/bzr/hg etc., SVN is currently experiencing the 
same fate, CVS experienced when SVN was new.

It was nice, when it was new, it had its time, but it also was largely 
hyped then and now is gradually fading away, because people now are 
considering git/bzr/hg to be superior (and are hyping it ;) )

Ralf

Re: GIT and CVS

[André Pönitz]

On Friday 14 October 2011 16:57:59 ext Phil Muldoon wrote:
> André Pönitz <andre.poenitz@nokia.com> writes:
> > * "Git sucks on MS-Windows". Git is usable on Windows to a degree that projects
> > much bigger than gdb switched to it, after careful consideration of a lot of
> > alternatives, including commercial offerings. My main work currently is on a
> > smaller cross platform project about 3/4 the "total size" of gdb (including
> > bfd, libiberty,  etc) and this is certainly in a very usable state on Windows.
> 
> That's interesting, is there an active community around GIT there?

I think there's a community around msys. google finds something. I don't 
really know myself as I've never felt the urge to get in to touch with them,
git just works "well enough" for us. It is indeed noticably slower than on
Linux, but that's pretty much the same for SVN, or completely unrelated 
things like compilation with gcc. 

We are also using it in a MinGW based environment, i.e. pretty much in the 
same context as Eli's setup, so I am really not sure why our experiences
differ so much. Perhaps it's really the integration with the emacs VCS interface
that makes the difference here. But then, editor integrations are fixable ;-}

Andre'

Re: GIT and CVS

[Pedro Larroy]

Why not mercurial? it's more user friendly than git, and better cross
platform support.


Regards.

On Thu, Oct 13, 2011 at 9:37 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>
> At the risk of atomizing the poor horse, I want to refresh ideas and
> thoughts on this.
>
> First, I'll point out I am in favor of GIT.  Not because GIT has won me
> over heart-and-soul, but purely because I can work on GDB GIT offline.
> This is not an inconsiderable benefit.  I can create local check-ins,
> create branches, merge, cherry-pick all in the leisure of my own office,
> or garden, or airport ... without internet access.
>
> So that is my bias laid out.
>
> So why are we still on CVS?  I'm not a release manager, so I do not have
> to do the difficult work of cutting branches, and all of the difficult
> work in making releases.  But what are the objections to GIT?
> Personally, I'll give a strong bias to Joel's opinions because, frankly,
> he has to deal with this issue far more than any other.
>
> GIT is, I think, available everywhere, has a CVS interface, and is
> far, far quicker than CVS.  Maybe with the stronger identity and
> information that comes with GIT logs we can finally retire
> ChangeLogs.
>
> CVS has served very well over the years.  I, and many others, cut our
> teeth on it.  It's been a good system.  But beyond stability I
> don't see it keeping up with functionality of other repository systems.
> I find myself working on GIT 98% of the time, and the other 2% dealing
> with CVS on the final check-in.  Surely I can't be the only hacker that
> does this?  If the vast majority are in this work-flow, perhaps we
> should think about the pros and the cons again.  I have no ideas about
> the work-flows of my GDB hackers, and if, you know, we are all doing this
> then we should recognize the elephant in the room.  If not, then I will
> go happily into the (CVS) night, content on the validity of its use and
> utility.
>
> So, what do you think?
>
> Cheers,
>
> Phil
>

Re: GIT and CVS

[Steinar Bang]

>>>>> Pedro Larroy <pedro.larroy.lists@gmail.com>:

> Why not mercurial? it's more user friendly than git, and better cross
> platform support.

Is mercurial good at doing branching and merging?

Re: GIT and CVS

[John Hein]

Steinar Bang wrote at 09:28 +0100 on Nov 12, 2011:
 > Is mercurial good at doing branching and merging?

Quite good.

http://lmgtfy.com/?q=mercurial+branching+merging

Re: GIT and CVS

[Tom Tromey]

>>>>> "Pedro" == Pedro Larroy <pedro.larroy.lists@gmail.com> writes:

Pedro> Why not mercurial? it's more user friendly than git, and better cross
Pedro> platform support.

To answer your question, most active gdb developers are already using
git and just use CVS for the final commit.


But let's end this thread.  We've had this discussion several times now
and haven't learned anything new since (see point 6):

    http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html

The problem has been the lack of manpower, and perhaps willpower, to do
the actual work.

Tom

Re: GIT and CVS

[Christopher Faylor]

On Tue, Nov 15, 2011 at 08:02:24AM -0700, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Larroy <pedro.larroy.lists@gmail.com> writes:
>
>Pedro> Why not mercurial? it's more user friendly than git, and better cross
>Pedro> platform support.
>
>To answer your question, most active gdb developers are already using
>git and just use CVS for the final commit.
>
>
>But let's end this thread.  We've had this discussion several times now
>and haven't learned anything new since (see point 6):
>
>    http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html
>
>The problem has been the lack of manpower, and perhaps willpower, to do
>the actual work.

I'd be happy to do the actual work on sourceware (I think this is long
overdue) but I'm not keen on prospect of dealing with the more
"political" nature of this issue.  So maybe that's the willpower part.

cgf