headers
Joel Brobecker | 1 Jan 2010 09:01
Favicon

time to be serious about dropping CVS

Hello everyone,

Happy New Year!

Since I started using SVN, and even more so since I started using git,
I have found that using CVS is very inconvenient, bordering on unbearable.
But now that I'm making massive mechanical changes (Start of New Year
procedure), I am really having a hard time accepting it - Just to do a diff
in order to verify my changes took 11mins. Same for the commit.  Another
smaller diff aborted 2mins after I started it because I made a mistake
in the command line.

There is no reason why every contributor should be continuing to waste
more time because we're stuck with an outdated tool.

I am prepared to do whatever it takes to switch to either SVN or git.
The problem is that i don't know how to solve the one sticky issue
of partial-checkouts :-).

Right now, git is so much more powerful and fast, that I will personally
focus on a transition to git.  What I'd like to do is for a group of
motivated contributors to form a "task force" whose goal is to come up
with possible suggestions on how to transition, and then offer them up
for review, with pros and cons, to the maintainers of the affected
projects.  Target date - I'm thinking sometime during the summer,
maybe the GCC Summit? At the very latest, end of year 2010.

Anyone interested, please email me.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Jan 2010 09:37
Picon

Re: time to be serious about dropping CVS

> Date: Fri, 1 Jan 2010 12:01:37 +0400
> From: Joel Brobecker <brobecker <at> adacore.com>
> 
> Right now, git is so much more powerful and fast, that I will personally
> focus on a transition to git.

If it is going to be git, then I would request to set up a two-way
(i.e., writable) gateway for bzr, cvs, or svn (in that order of
preference).

All of my GDB related work is done on a Windows machine at home, with
native Windows tools, and I have no resources to deal with the
complications that are imminent when a Windows (MSYS) port of git is
installed in parallel to an otherwise native win32 development
environment.

If none of such gateways will be available when CVS access is shut
down, I will regretfully resign from my GDB-related development work.
Permalink | Reply | 6 comments |
headers
Jan Kratochvil | 1 Jan 2010 09:40
Picon
Favicon

[patch] Fix crash on CLI indented comments [Re: [Bug:cli] Loading user-defined function generates an internal error]

On Wed, 30 Dec 2009 23:26:27 +0100, Nick Roberts wrote:
> Heres a simpler user defined function that gives a segmentation fault.  It
> appears that GDB can no longer handle indented comments.
> 
> define my_fun
>  #indented comment
> end

      (*command)->line = savestring (p, p1 - p);
#1  0x0000000000487405 in savestring (ptr=0x1d5dd31 "", size=18446744073709551615) at utils.c:1377
(gdb) p/x size
$1 = 0xffffffffffffffff
(gdb) p p
$2 = 0x1d5dd31 ""
(gdb) p p1
$3 = 0x1d5dd30 " "

OK to check-in? Probably [obv].

Thanks,
Jan

2010-01-01  Jan Kratochvil  <jan.kratochvil <at> redhat.com>

	* cli/cli-script.c (process_next_line): Check P2 overrun.

--- a/gdb/cli/cli-script.c
+++ b/gdb/cli/cli-script.c
 <at>  <at>  -893,7 +893,7  <at>  <at>  process_next_line (char *p, struct command_line **command, int parse_commands)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Joel Brobecker | 1 Jan 2010 09:59
Favicon

Re: time to be serious about dropping CVS

> If it is going to be git, then I would request to set up a two-way
> (i.e., writable) gateway for bzr, cvs, or svn (in that order of
> preference).

Understood, we will keep this in mind. Note for the record, that
I regularly do changes on Windows machines, and the cygwin git has
been working just fine. It's not as fast as on a Linux machine,
but still very much faster than anything else.

--

-- 
Joel
Permalink | Reply | 0 comments |
headers
Mark Kettenis | 1 Jan 2010 11:25
Picon
Picon
Favicon

Re: time to be serious about dropping CVS

> Date: Fri, 1 Jan 2010 12:01:37 +0400
> From: Joel Brobecker <brobecker <at> adacore.com>
> 
> Hello everyone,
> 
> Happy New Year!
> 
> Since I started using SVN, and even more so since I started using git,
> I have found that using CVS is very inconvenient, bordering on unbearable.
> But now that I'm making massive mechanical changes (Start of New Year
> procedure), I am really having a hard time accepting it - Just to do a diff
> in order to verify my changes took 11mins. Same for the commit.  Another
> smaller diff aborted 2mins after I started it because I made a mistake
> in the command line.
> 
> There is no reason why every contributor should be continuing to waste
> more time because we're stuck with an outdated tool.

SVN is acceptable.  I simply cannot wrap my head around git.  I've
tried.  There's no equivalent of a quick "cvs update" of a checked out
tree that contains modifications.  And I can't get myself to commit
half-finished or half-tested changes to a local repo.  And even when I
get over that barrier I'd need to think for a couple of minutes to
write an appopriate commit message.  So instead I find myself moving
modified source files out of my tree, spending half an hour browsing
the web to figure out how I can get back the origional unmodified
source file, update the tree, compare the new source file with the one
I saved and applying the changes by hand.

If we switch to using git, I'll probably stop contributing to GDB.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Jan 2010 11:35
Picon

Re: time to be serious about dropping CVS

> Date: Fri, 1 Jan 2010 12:59:24 +0400
> From: Joel Brobecker <brobecker <at> adacore.com>
> Cc: gdb <at> sourceware.org, binutils <at> sources.redhat.com
> 
> > If it is going to be git, then I would request to set up a two-way
> > (i.e., writable) gateway for bzr, cvs, or svn (in that order of
> > preference).
> 
> Understood, we will keep this in mind. Note for the record, that
> I regularly do changes on Windows machines, and the cygwin git has
> been working just fine.

That's just it: I cannot afford to install Cygwin and keep it in
workable shape, in parallel to native MinGW based development
environment.  I simply don't have enough free time for that.  What
little resources I have, I must use most of them for productive work,
not for tinkering with two subtly conflicting development
environments.
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 1 Jan 2010 11:35
Favicon

Re: [patch] Fix crash on CLI indented comments [Re: [Bug:cli] Loading user-defined function generates an internal error]

> 2010-01-01  Jan Kratochvil  <jan.kratochvil <at> redhat.com>
> 
> 	* cli/cli-script.c (process_next_line): Check P2 overrun.

Yes - I agree it's obvious when you know that the comment is stripped
upstream...

Approved. Thanks for fixing.

Given the number of regressions/failures we've seen in this area,
I really thought we should add a test for this, so I created
the attached patch.  I will commit after you have committed yours.

gdb/testsuite/

        Test indented comment in file being sourced.
        * commands.exp: Test indented comment in file being sourced.

Tested on x86_64-linux.  Fails miserably without Jan's patch.

--

-- 
Joel
Attachment (test-indented-comment.diff): text/x-diff, 1246 bytes
Permalink | Reply | 4 comments |
headers
Andreas Schwab | 1 Jan 2010 11:46

Re: time to be serious about dropping CVS

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

> There's no equivalent of a quick "cvs update" of a checked out tree
> that contains modifications.  And I can't get myself to commit
> half-finished or half-tested changes to a local repo.

That's what "git stash" is for.

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Permalink | Reply | 0 comments |
headers
Jan Kratochvil | 1 Jan 2010 12:00
Picon
Favicon

Re: [patch] Fix crash on CLI indented comments [Re: [Bug:cli] Loading user-defined function generates an internal error]

On Fri, 01 Jan 2010 11:35:20 +0100, Joel Brobecker wrote:
> Approved. Thanks for fixing.

Checked-in.

>         Test indented comment in file being sourced.
>         * commands.exp: Test indented comment in file being sourced.

OK, thanks for this work.

Regards,
Jan

http://sourceware.org/ml/gdb-cvs/2010-01/msg00014.html

--- src/gdb/ChangeLog	2010/01/01 09:44:05	1.11190
+++ src/gdb/ChangeLog	2010/01/01 10:57:42	1.11191
 <at>  <at>  -1,3 +1,7  <at>  <at> 
+2010-01-01  Jan Kratochvil  <jan.kratochvil <at> redhat.com>
+
+	* cli/cli-script.c (process_next_line): Check P2 overrun.
+
 2009-01-01  Joel Brobecker  <brobecker <at> adacore.com>

 	Update the copyright hearder to add year 2010 for most GDB files.
--- src/gdb/cli/cli-script.c	2010/01/01 07:31:47	1.55
+++ src/gdb/cli/cli-script.c	2010/01/01 10:57:43	1.56
 <at>  <at>  -893,7 +893,7  <at>  <at> 

   p2 = p;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Brobecker | 1 Jan 2010 12:02
Favicon

Re: time to be serious about dropping CVS

> I simply cannot wrap my head around git.

I understand how you feel, since I went through the same process,
particularly since I started using it a while ago, when the user
interface was, er, rough. Fortunately, it has come a long way and
is a lot better, now.

I will not deny that learning git takes a bit of effort. But, I truly
wholeheartedly believe that the initial pain is well worth the effort,
because it's going to help save so much time later - everything is easier
and faster with git. There's just this initial hump at the beginning.

There is a great book for learning git relatively quickly, and it is
even available on the web: Pro git.  It's one of the rare books that
I read from cover to cover.

    http://progit.org/

That being said, we can help you in a way that you will not have to
learn much git. If we ever switch to git, we will provide a detailed
procedure, recipes really, on how to do with git all the usual operations
that most contributors need.

For instance, to put your changes aside, just "git stash". To reapply
them again: "git stash pop". But you'll soon learn that even that is
not easy enough, and before you know it, you'll naturally be using branches.
If you're managing a set of patches (eg for a new port, or a new feature),
you'll love "git rebase".

> If we switch to using git, I'll probably stop contributing to GDB.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane