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

[Joseph S. Myers]

Post by Phil Muldoon
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>.

Post by Phil Muldoon
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).

[Phil Muldoon]

Post by Joseph S. Myers

Post by Phil Muldoon
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.

Post by Joseph S. Myers
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

[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)

[Phil Muldoon]

Post by 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?

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

[Alfred M. Szmidt]

Post by Joseph S. Myers

Post by Phil Muldoon
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.

Post by Joseph S. Myers
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 Kratochvil]

Post by 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.

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


Regards,
Jan

[Eli Zaretskii]

Date: Thu, 13 Oct 2011 23:50:20 +0200
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.)

[Jan Kratochvil]

Post by Eli Zaretskii
??? When did you last use "git annotate"? and on what project?

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

Post by Eli Zaretskii
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

[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

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

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 00:24:41 +0200

Post by Eli Zaretskii
??? When did you last use "git annotate"? and on what project?

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

Post by Eli Zaretskii
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.

[Alfred M. Szmidt]

Post by 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.

[Jan Kratochvil]

Post by Alfred M. Szmidt
* 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

Post by Alfred M. Szmidt
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.

Post by Alfred M. Szmidt
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

[Alfred M. Szmidt]

Post by Alfred M. Szmidt
* 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.

Post by Alfred M. Szmidt
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 <***@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 <***@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.
....

Post by Alfred M. Szmidt
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.

[Jan Kratochvil]

Post by Alfred M. Szmidt

Post by Alfred M. Szmidt
* configure.ac (tic6x-*-*): Remove gdb from noconfigdirs.

tic6x-*-*)
- noconfigdirs="$noconfigdirs gdb sim"
+ noconfigdirs="$noconfigdirs sim"
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

[...]

Post by 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.

Post by Alfred M. Szmidt
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.

Post by Alfred M. Szmidt
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).

Post by Alfred M. Szmidt
Implement new DWARF macro proposal. (Bug#123456)
URL: http://sourceware.org/ml/gdb-patches/2011-07/msg00732.html

[...]

Post by Alfred M. Szmidt
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

[Alfred M. Szmidt]

Post by 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?

Post by Alfred M. Szmidt
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. :-)

Post by Alfred M. Szmidt
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.

[Phil Muldoon]

Post by Phil Muldoon

Post by Joseph S. Myers

Post by Phil Muldoon
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?

Post by Phil Muldoon
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?

Post by Phil Muldoon

Post by Joseph S. Myers
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

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

[Jan Kratochvil]

Post by Phil Muldoon
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

Post by Phil Muldoon
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

[Alfred M. Szmidt]

Post by Phil Muldoon
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.

[Jan Kratochvil]

Post by Jan Kratochvil
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'.

Post by Jan Kratochvil
dejagnu gcc-gfortran gcc-java gcc-objc prelink fpc gcc-gnat glibc-static valgrind
And tcl.

(This is a dependency of dejagnu.)


Thanks,
Jan

[Alfred M. Szmidt]

Post by Jan Kratochvil
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.

[Joseph S. Myers]

Post by Jan Kratochvil
And when you commit GIT->CVS it took me for the last 12-parts patchser over an
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.

[Jan Kratochvil]

Post by Joseph S. Myers
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

[Joseph S. Myers]

Post by Phil Muldoon

Post by Joseph S. Myers

Post by Phil Muldoon
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.

Post by Phil Muldoon
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).

Post by Phil Muldoon
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.

[Jan Kratochvil]

Post by Joseph S. Myers
Even with local disk, git is much more I/O intensive. I timed looking at
$ 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

[Joseph S. Myers]

Post by Jan Kratochvil
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.

[Eli Zaretskii]

Date: Thu, 13 Oct 2011 23:59:28 +0200

Post by Joseph S. Myers
Even with local disk, git is much more I/O intensive. I timed looking at
$ 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.

[Joel Brobecker]

Post by Eli Zaretskii
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.

[Eli Zaretskii]

Date: Thu, 13 Oct 2011 22:02:45 -0700
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.

[Phil Muldoon]

Post by Joseph S. Myers

Post by Phil Muldoon

Post by Joseph S. Myers

Post by Phil Muldoon
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?

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

Post by Joseph S. Myers
* 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.

Post by Joseph S. Myers
* 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.

Post by Joseph S. Myers

Post by Phil Muldoon
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.

Post by Joseph S. Myers

Post by Phil Muldoon
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
$ 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.

Post by Joseph S. Myers
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

[Joseph S. Myers]

Post by Phil Muldoon

Post by Joseph S. Myers
* 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.

Post by Phil Muldoon
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.

[Jan Kratochvil]

Post by Joseph S. Myers
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

[Eli Zaretskii]

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.

[Phil Muldoon]

Post by Eli Zaretskii

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.

Post by Eli Zaretskii
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?

Post by Eli Zaretskii
(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?

Post by Eli Zaretskii
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

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 00:20:34 +0100

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
(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.

Post by Eli Zaretskii
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.

[Mark Kettenis]

Date: Fri, 14 Oct 2011 10:13:31 +0200

Post by Phil Muldoon

Post by Eli Zaretskii
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?

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 12:22:53 +0200 (CEST)
$ 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.

[Li, Rongsheng]

Anyone remember how to unbscribe this ?

Thanks

Ken

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

Date: Fri, 14 Oct 2011 12:22:53 +0200 (CEST)
$ 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.

[Jan Kratochvil]

Post by Mark Kettenis
$ cvs update
(test changes, write changelog, send diff for review)

[...]

Post by Mark Kettenis
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)

Post by Mark Kettenis
and I have to commit half-finished work,

You don't have to.

Post by Mark Kettenis
(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

[Jonas Maebe]

Post by Jan Kratochvil

Post by Mark Kettenis
(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

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 14:53:56 +0200

Post by Mark Kettenis
$ cvs update
(test changes, write changelog, send diff for review)

[...]

Post by Mark Kettenis
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.

Post by Mark Kettenis
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.

[Jan Kratochvil]

Post by Eli Zaretskii
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.

Post by Eli Zaretskii

Post by Jan Kratochvil

Post by Mark Kettenis
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

[Phil Muldoon]

Post by Eli Zaretskii

Date: Fri, 14 Oct 2011 14:53:56 +0200

Post by Mark Kettenis
$ cvs update
(test changes, write changelog, send diff for review)

[...]

Post by Mark Kettenis
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.

Post by Eli Zaretskii

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

Post by Mark Kettenis
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

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 16:05:37 +0100

Post by Eli Zaretskii
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.

[Phil Muldoon]

Post by Mark Kettenis

Date: Fri, 14 Oct 2011 10:13:31 +0200

Post by Phil Muldoon

Post by Eli Zaretskii
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
$ cvs update
(make some changes)

git pull will fetch and merge changes.

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

Same as above.

Post by Mark Kettenis
$ cvs update
(test changes, write changelog, send diff for review)
...

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

Post by Mark Kettenis
$ cvs update
(test changes again, fixup changelog)

No difference.

Post by Mark Kettenis
$ cvs commit

git commit

then

git push

Post by Mark Kettenis
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.

Post by Mark Kettenis
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.

Post by Mark Kettenis
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.

Post by Mark Kettenis
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

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 15:51:40 +0100

Post by Mark Kettenis
$ 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".

Post by Mark Kettenis
$ 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.

Post by Mark Kettenis
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"?

[Jonas Maebe]

Date: Fri, 14 Oct 2011 15:51:40 +0100

Post by Phil Muldoon
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

[Andreas Schwab]

Post by Eli Zaretskii
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]

Post by Eli Zaretskii

Post by Phil Muldoon
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.

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 18:11:40 +0200

Post by Eli Zaretskii

Post by Phil Muldoon
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".

[Matt Rice]

Date: Fri, 14 Oct 2011 18:11:40 +0200

Post by Eli Zaretskii

Post by Phil Muldoon
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

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 09:59:03 -0700

Date: Fri, 14 Oct 2011 18:11:40 +0200

Post by Eli Zaretskii

Post by Phil Muldoon
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.

[Steinar Bang]

Post by Mark Kettenis
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
$ cvs update
(make some changes)

git pull
make some changes

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

Post by Mark Kettenis
...
(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)

Post by Mark Kettenis
...
$ 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)

Post by Mark Kettenis
...
$ 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)

Post by Mark Kettenis
$ 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.

[Eli Zaretskii]

Date: Fri, 11 Nov 2011 21:47:43 +0100

Post by Mark Kettenis
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
$ 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.

[Steinar Bang]

Post by Eli Zaretskii
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.)

Post by Eli Zaretskii
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...?

Post by Eli Zaretskii
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...:-)

[Joel Brobecker]

Post by Phil Muldoon
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.

[Joseph S. Myers]

Post by Joel Brobecker
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.

[André Pönitz]

Post by 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.

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.

Post by Phil Muldoon
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'

[Eli Zaretskii]

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.

[Phil Muldoon]

Post by Eli Zaretskii

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?

Post by Eli Zaretskii

* 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

[Eli Zaretskii]

Date: Fri, 14 Oct 2011 16:01:38 +0100

Post by Eli Zaretskii

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.

[André Pönitz]

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

[Phil Muldoon]

Post by André Pönitz
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.

Post by André Pönitz
So...
I personally don't _like_ git.

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

Post by André Pönitz
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.

Post by André Pönitz
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.

Post by André Pönitz
* 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
.

Post by André Pönitz
* "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?

Post by André Pönitz
* 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

[P***@Dell.com]

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 a

[Ralf Corsepius]

Post by P***@Dell.com
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.

Post by P***@Dell.com
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.

Post by P***@Dell.com
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

[André Pönitz]

Post by Phil Muldoon

Post by André Pönitz
* "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'

[Pedro Larroy]

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


Regards.

Post by 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

[Steinar Bang]

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

Is mercurial good at doing branching and merging?

[John Hein]

Post by Steinar Bang
Is mercurial good at doing branching and merging?

Quite good.

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

[Tom Tromey]

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

[Christopher Faylor]

Post by Tom Tromey
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
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