From: Jim Blandy <jimb@red-bean.com>
To: Joel Brobecker <brobecker@adacore.com>,
"Joseph S. Myers" <joseph@codesourcery.com>,
gdb@sourceware.org, binutils@sources.redhat.com
Subject: Re: time to be serious about dropping CVS
Date: Tue, 21 Dec 2010 03:46:00 -0000 [thread overview]
Message-ID: <AANLkTim_S_=4d1gbGgJOeFYEZDeTHN3oHchTL2+dSORc@mail.gmail.com> (raw)
In-Reply-To: <20101221032725.GS2618@adacore.com>
As one of the original designers of SVN, I really recommend switching
to either git or Mercurial. It takes some getting used to, but any GDB
hacker can handle that challenge. Once you switch, you will love the
speed so much you'll cry when you have to use CVS (or SVN).
Perhaps it would help to declare git usage questions from contributors
"on topic" for the GDB lists, at least for a few months, so the
developers familiar with the tools can help out the others.
On 12/20/10, Joel Brobecker <brobecker@adacore.com> wrote:
>> Just checking: is your task force still on target to have proposals by the
>>
>> end of the year? A report on progress would be good even if there aren't
>> full proposals yet.
>
> I am a bit ashamed, but I have procrastinated :-(. I was introduced
> a while ago to the "git cvsexportcommit" command, which effectively
> allows me to work exclusively in git, thanks to our git mirror.
> The only downsides at, the moment, are: The git mirror is only updated
> every 30mins, and I need to do a CVS update before I push a commit
> from git to CVS. On the other hand of the equation, we have a number
> of hurdles to face before a conversion can be started, and the problem
> is that the hurdles are not all just technical (multiple projects sharing
> portions of the same repository), but human as well (convincing people
> to change).
>
> So the balance of benefits versus effort made me give up a bit on
> the idea, at least for now. For now, in order for this to happen,
> we would have to change something in the way we either get the sources,
> or in the way we build, or both. We might also not be able to do
> the transition just on our own, and that means coordination with
> other projects, etc. Perhaps, as more git features appear, we might
> be able to find a simpler way to transition, and that could be
> the trigger for transition to really start...
>
> One of the things that we could think about, is getting away from
> our 'partial checkout' way of getting the sources. It's convenient,
> but it is also makes us utterly dependent on CVS. I think there is
> a simple solution to that:
> (1) Separate out the projects that could go on to live their lives
> on their own (Eg: expect, tcl, tck, winsup, rda, etc)
> (2) And for the remaining projects, either:
> (a) Share one large repository: We would have to change the way
> we configure or the "make" command we use to build;
> (b) Have our own set of sources, with synchronization issues
> (which if effectively the same as (1), really).
> Option (1) is not strictly necessary for option (2a), but I think
> it would be a good cleanup, and probably benficial to those projects
> too - as they would be getting more freedom, I think. I just realized
> for instance that dejagnu is no longer part of src/. It's under git,
> now.
>
> The problem is that you have to convince people that all these changes
> are desirable, and that, I think, is more difficult than the technical
> work itself...
>
> --
> Joel
>
next prev parent reply other threads:[~2010-12-21 3:46 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-01 8:02 Joel Brobecker
2010-01-01 8:35 ` Eli Zaretskii
2010-01-01 9:00 ` Joel Brobecker
2010-01-01 10:34 ` Eli Zaretskii
2010-01-01 15:39 ` Matthias Urlichs
2010-01-01 15:49 ` Eli Zaretskii
2010-01-01 10:26 ` Mark Kettenis
2010-01-01 10:46 ` Andreas Schwab
2010-01-01 11:03 ` Joel Brobecker
2010-01-01 16:06 ` Matthias Urlichs
2010-01-01 17:57 ` H.J. Lu
2010-01-01 13:00 ` Joseph S. Myers
2010-01-01 14:18 ` Joel Brobecker
2010-01-02 18:11 ` Christopher Faylor
2010-01-02 19:08 ` Christopher Faylor
2010-01-03 13:52 ` Matthias Urlichs
2010-01-08 12:58 ` Phil Muldoon
2010-01-08 13:08 ` Tristan Gingold
2010-01-08 13:20 ` Joel Brobecker
2010-01-08 13:26 ` Tristan Gingold
2010-01-08 13:13 ` Joel Brobecker
2010-01-08 13:21 ` Jonas Maebe
2010-01-08 13:34 ` Andreas Schwab
2010-01-08 13:14 ` Jonas Maebe
2010-01-08 18:41 ` Michael Snyder
2010-01-08 18:49 ` Paul Koning
2010-12-20 17:35 ` Joseph S. Myers
2010-12-21 3:27 ` Joel Brobecker
2010-12-21 3:46 ` Jim Blandy [this message]
2010-12-21 7:16 ` Pascal Obry
2010-12-21 15:14 ` Tom Tromey
2010-12-21 16:15 ` Christopher Faylor
2010-12-21 18:39 ` Joseph S. Myers
2010-12-21 19:26 ` Tom Tromey
2010-12-21 18:42 ` Joseph S. Myers
2010-12-21 19:21 ` DJ Delorie
2010-12-22 15:23 ` Christopher Faylor
2010-12-22 15:29 ` NightStrike
2010-12-22 16:48 ` Joseph S. Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTim_S_=4d1gbGgJOeFYEZDeTHN3oHchTL2+dSORc@mail.gmail.com' \
--to=jimb@red-bean.com \
--cc=binutils@sources.redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=joseph@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox