time to be serious about dropping CVS

time to be serious about dropping CVS

[Joel Brobecker]

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.

-- 
Joel

Re: time to be serious about dropping CVS

[Eli Zaretskii]

> Date: Fri, 1 Jan 2010 12:01:37 +0400
> From: Joel Brobecker <brobecker@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.

Re: time to be serious about dropping CVS

[Joel Brobecker]

> 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

Re: time to be serious about dropping CVS

[Eli Zaretskii]

> Date: Fri, 1 Jan 2010 12:59:24 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sourceware.org, binutils@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.

Re: time to be serious about dropping CVS

[Matthias Urlichs]

On Fri, 2010-01-01 at 10:37 +0200, Eli Zaretskii wrote:
> 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). 

git comes with a two-way CVS gateway.

Re: time to be serious about dropping CVS

[Eli Zaretskii]

> From: Matthias Urlichs <matthias@urlichs.de>
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb@sourceware.org,  binutils@sources.redhat.com
> Date: Fri, 01 Jan 2010 16:39:15 +0100
> 
> On Fri, 2010-01-01 at 10:37 +0200, Eli Zaretskii wrote:
> > 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). 
> 
> git comes with a two-way CVS gateway.

Thanks, that'd be fine with me.

Re: time to be serious about dropping CVS

[Mark Kettenis]

> Date: Fri, 1 Jan 2010 12:01:37 +0400
> From: Joel Brobecker <brobecker@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.

Re: time to be serious about dropping CVS

[Andreas Schwab]

Mark Kettenis <mark.kettenis@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: time to be serious about dropping CVS

[Joel Brobecker]

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

We'll have ways to allow you to work comfortably, be it SVN or a git-cvs
server.

-- 
Joel

Re: time to be serious about dropping CVS

[Matthias Urlichs]

On Fri, 2010-01-01 at 11:25 +0100, Mark Kettenis wrote:
> There's no equivalent of a quick "cvs update" of a checked out
> tree that contains modifications. 

That's a bad habit from CVS/SVN usage which you should train yourself
out of. It's the cause of many a "my half-tested changes don't work at
all after the cvs update, how the hell do I figure out what went wrong"
trap I've fallen into before switching to git. No longer: a script which
runs a git_bisect/apply_my_change/test/repeat-until-culprit-is-found
is so cheap that I write it from scratch every time I need it.

This, by the way, is just one command where git _really_ shines.
Consider: You just updated from GCC 4.3 to 4.4. One of your tests shows
a regression. You want to figure out which of the 4527 patches and/or
293 merges which went into 4.4 caused it, so as to fix the regression
and/or render a qualified bug report and/or figure out how to circumvent
the problem. With "git bisect", this requires less than 15 compile/test
cycles (ceil(log2(4527+293))) and can be fully automated. 

(Yes, the numbers of patches and merges are made up.)

> And I can't get myself to commit half-finished or half-tested changes
> to a local repo.

Somebody else already mentioned "git stash". Writing a small script
which does a stash/merge/stash_pop, or a commit/merge/rebase, is
trivial. Problem solved.


SVN is _not_ acceptable for anybody who ever tried to do nontrivial work
when disconnected, e.g. on an airplane. Among other problems.

Please select a distributed VCS. SVN is not.

Re: time to be serious about dropping CVS

[H.J. Lu]

On Fri, Jan 1, 2010 at 8:05 AM, Matthias Urlichs <matthias@urlichs.de> wrote:
> SVN is _not_ acceptable for anybody who ever tried to do nontrivial work
> when disconnected, e.g. on an airplane. Among other problems.
>
> Please select a distributed VCS. SVN is not.
>
>

Agreed. I have switched my gcc, binutils, gdb and glibc work to git. It is
so much better than svn. I regularly work on N different patches, each on
a different branch, at the same time. When they are done, I create a new
branch from trunk and do

# git merge

to merge them with minimum editing so that I can test them together.
When something goes wrong, I can fix it on problem branches and
do another merge.

"git revert" was also nice. I have used it more than once when I
checked in something which was totally broken.

BTW, I found this

http://cheat.errtheblog.com/s/git

was helpful to me.

-- 
H.J.

Re: time to be serious about dropping CVS

[Joseph S. Myers]

Since you sent this to the GDB and Binutils lists, I'll just repeat one 
point from my previous comments, which are all in the list archives.

Do not try to plan a transition for the whole src repository.  Try to plan 
one for GDB and Binutils together at most [*], on the basis that other 
projects such as Cygwin and Newlib should choose their own version control 
systems in their own way and at such times as are convenient to them.  
Thus you should operate on the basis that the shared toplevel files will 
always need merging between multiple repositories using multiple version 
control systems, simply because the various projects using them are 
independently run and should not be constrained to use a single system.

My suggestion is to handle the shared toplevel files in a DVCS-pure way - 
no one master repository, changes committed to any repository get merged 
to the others automatically.  But a separate master for them with all 
commits to them in the trunk of other repositories being rejected unless 
marked as merges from the master would be reasonable as well - as long as 
you don't constrain the repositories all to use the same VCS.

[*] I leave open the question of whether Insight is considered part of GDB 
here - though making it a GDB branch rather than something present on the 
trunk might be a possibility with a VCS with better merging than CVS.  I 
consider sim part of GDB here.  I consider the cpu/ directory as part of 
binutils (necessarily, as the source code of some binutils files), but 
cgen/ as a separate project.  I do not think there should be tcl/ and tk/ 
directories in the new GDB repository.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: time to be serious about dropping CVS

[Joel Brobecker]

Thanks for the suggestions!

> Do not try to plan a transition for the whole src repository.  Try to plan 
> one for GDB and Binutils together at most [*], on the basis that other 
> projects such as Cygwin and Newlib should choose their own version control 
> systems in their own way and at such times as are convenient to them.  

I would be happy with such an approach - in fact, I think that makes
the task easier too, since we'd have fewer groups to coordinate.

> My suggestion is to handle the shared toplevel files in a DVCS-pure way - 
> no one master repository, changes committed to any repository get merged 
> to the others automatically.

I think GCC has something more or less similar where they have a semi-
automated merge mechanism? That would perfectly work for me.

-- 
Joel

Re: time to be serious about dropping CVS

[Christopher Faylor]

On Fri, Jan 01, 2010 at 06:18:06PM +0400, Joel Brobecker wrote:
>Thanks for the suggestions!
>
>> Do not try to plan a transition for the whole src repository.  Try to plan 
>> one for GDB and Binutils together at most [*], on the basis that other 
>> projects such as Cygwin and Newlib should choose their own version control 
>> systems in their own way and at such times as are convenient to them.  
>
>I would be happy with such an approach - in fact, I think that makes
>the task easier too, since we'd have fewer groups to coordinate.

Although I'd like to move Cygwin to git, I really and sincerely think
that making Cygwin part of the source tree for gdb and binutils is a
historical mistake.  I'd love to rectify it.

I'll be happy to assist in setting things up for git on sourceware.  I
think it's time that all of the random git processes that are running
there should somehow be consolidated.  If that makes sense.

>>My suggestion is to handle the shared toplevel files in a DVCS-pure way
>>- no one master repository, changes committed to any repository get
>>merged to the others automatically.
>
>I think GCC has something more or less similar where they have a semi-
>automated merge mechanism?  That would perfectly work for me.

I'm a real novice when it comes to git.  Does it allow "merging" two
separate repositories?  Could we have a separate repository containing
the configury and libiberty which was shared between gdb/binutils/gcc?

cgf

Re: time to be serious about dropping CVS

[Christopher Faylor]

On Sat, Jan 02, 2010 at 01:11:34PM -0500, Christopher Faylor wrote:
>On Fri, Jan 01, 2010 at 06:18:06PM +0400, Joel Brobecker wrote:
>>Thanks for the suggestions!
>>
>>> Do not try to plan a transition for the whole src repository.  Try to plan 
>>> one for GDB and Binutils together at most [*], on the basis that other 
>>> projects such as Cygwin and Newlib should choose their own version control 
>>> systems in their own way and at such times as are convenient to them.  
>>
>>I would be happy with such an approach - in fact, I think that makes
>>the task easier too, since we'd have fewer groups to coordinate.
>
>Although I'd like to move Cygwin to git, I really and sincerely think
>that making Cygwin part of the source tree for gdb and binutils is a
>historical mistake.  I'd love to rectify it.

Hmm.  On rereading the "Although" above doesn't really belong there
since I was just expressing my support for the idea.  Sorry for the
lack of clarity.

cgf

Re: time to be serious about dropping CVS

[Matthias Urlichs]

On Sat, 2010-01-02 at 13:11 -0500, Christopher Faylor wrote:
> I'm a real novice when it comes to git.  Does it allow "merging" two
> separate repositories? 

Yes.

Re: time to be serious about dropping CVS

[Phil Muldoon]

On 01/01/2010 08:01 AM, Joel Brobecker wrote:
> 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.

Beyond the usual arguments and cons about CVS, the one thing that
really bites is that CVS always has to talk to a remote server.  It is
not distributed, so there is no local repository copy.  On a small
project that is ok, but currently diffs with GDB CVS take 12-15
minutes.  Commits are the same.  The same operations in GIT take
seconds.  It is even worse in the US 8am - 6pm hours.  This might be
because I live in the UK, and the server is on another continent.
Maybe folks closer to the server get a snappier response.  But if
there was problem that a distributed version control system was meant
to fix, it was this.

I don't know why CVS is so slow.  Whether it is CPU bound on the
sourceware machine, or the bandwidth at the hosting site is at
capacity .. who knows?  I'm not even sure how to find out.  But would
SVN solve any of the problem relating to performance?

My preference is for GIT, simply because of the speed.

Cheers,

Phil

Re: time to be serious about dropping CVS

[Tristan Gingold]

On Jan 8, 2010, at 1:58 PM, Phil Muldoon wrote:

> On 01/01/2010 08:01 AM, Joel Brobecker wrote:
>> 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.
> 
> Beyond the usual arguments and cons about CVS, the one thing that
> really bites is that CVS always has to talk to a remote server.

[...]

Agreed.

> My preference is for GIT, simply because of the speed.

Sure.
I now always work on gdb.git (from git mirror) but still use CVS to do my commit.  Using this approach
makes the switch much less necessary (IMHO).

Tristan.

Re: time to be serious about dropping CVS

[Joel Brobecker]

> Sure.  I now always work on gdb.git (from git mirror) but still use
> CVS to do my commit.  Using this approach makes the switch much less
> necessary (IMHO).

I disagree entirely. We're wasting time everytime someone does a commit.
I think I spend about half a day doing the copyright year updates, and
in the end, I decided to simply stop checking the diffs before doing
the commit, since getting a diff was simply taking too much time.
Regardless of what we end up choosing, there is no doubt in my mind
that we must stop using CVS ASAP.

You guys also don't have to deal with branches, but branches just do
not work neither with CVS, nor with SVN.

I realize that this discussing might seem a little deja-vu and boring,
so I'll stop now, and spend the energy on working on an alternative.
-- 
Joel

Re: time to be serious about dropping CVS

[Tristan Gingold]

On Jan 8, 2010, at 2:20 PM, Joel Brobecker wrote:

>> Sure.  I now always work on gdb.git (from git mirror) but still use
>> CVS to do my commit.  Using this approach makes the switch much less
>> necessary (IMHO).
> 
> I disagree entirely. We're wasting time everytime someone does a commit.
> I think I spend about half a day doing the copyright year updates, and
> in the end, I decided to simply stop checking the diffs before doing
> the commit, since getting a diff was simply taking too much time.
> Regardless of what we end up choosing, there is no doubt in my mind
> that we must stop using CVS ASAP.

I agree.  I should have said 'less urgent'.  I also sympathize with the copyright year work.

> You guys also don't have to deal with branches, but branches just do
> not work neither with CVS, nor with SVN.

Yes, I agree.  Back-porting is boring.  For binutils I have a script that does the work from the
commit mail.

> I realize that this discussing might seem a little deja-vu and boring,
> so I'll stop now, and spend the energy on working on an alternative.

Good luck!
Tristan.

Re: time to be serious about dropping CVS

[Joel Brobecker]

> I don't know why CVS is so slow.  Whether it is CPU bound on the
> sourceware machine, or the bandwidth at the hosting site is at
> capacity .. who knows?  I'm not even sure how to find out.  But would
> SVN solve any of the problem relating to performance?

My observations on SVN is that it is a huge I/O hog. I don't know
what it's doing, and how it encodes it's meta data, but you definitely
feel it when your home directory is not on a local hard drive.

-- 
Joel

Re: time to be serious about dropping CVS

[Jonas Maebe]

On 08 Jan 2010, at 14:12, Joel Brobecker wrote:

>> I don't know why CVS is so slow.  Whether it is CPU bound on the
>> sourceware machine, or the bandwidth at the hosting site is at
>> capacity .. who knows?  I'm not even sure how to find out.  But would
>> SVN solve any of the problem relating to performance?
>
> My observations on SVN is that it is a huge I/O hog. I don't know
> what it's doing, and how it encodes it's meta data, but you definitely
> feel it when your home directory is not on a local hard drive.

That's indeed true. As far as I know, it's due to svn creating lock  
files (or lock attributes) in every sub directory of the current  
working directory when performing any operation that might modify  
anything (unless you perform a non-recursive operation, but those are  
rare). I guess the reason is that svn allows treating every  
subdirectory as a separate "repository" should you wish to do so, so  
e.g. a commit in gdb/intl could be executed in parallel with an update  
gdb/bfd, since both would be locked separately. The downside is  
obviously that  updating gdb requires locking gdb/ and also all of its  
subdirectories.

Afaik, in case of git the entire repository is atomic and hence it  
doesn't have to lock/unlock all the subdirectories every time.


Jonas

Re: time to be serious about dropping CVS

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

> My observations on SVN is that it is a huge I/O hog. I don't know
> what it's doing, and how it encodes it's meta data, but you definitely
> feel it when your home directory is not on a local hard drive.

SVN spreads out its meta data in every tracked directory (like CVS), and
when you do an update it has to update files in every such directory.
Most modern VCS keep the meta data in a single directory.

Andreas.

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

Re: time to be serious about dropping CVS

[Jonas Maebe]

On 08 Jan 2010, at 13:58, Phil Muldoon wrote:

> I don't know why CVS is so slow.  Whether it is CPU bound on the
> sourceware machine, or the bandwidth at the hosting site is at
> capacity .. who knows?  I'm not even sure how to find out.  But would
> SVN solve any of the problem relating to performance?

Probably, yes. CVS does virtually everything on the server. A cvs diff  
sends a full copy of every potentially modified local file (i.e.,  
those of which the time stamp has changed) to the remote server, the  
server diffs it, and then sends a diff back to the client. Similarly,  
when you commit then a complete copy of all potentially modified local  
files is sent to the server, instead of only a diff, and the server  
has to create a diff. In case of svn, all the diff'ing is done on the  
client side and the client only ever sends diffs to the server (of  
actually modified files).

Of course, git can do even more on the client side.


Jonas

Re: time to be serious about dropping CVS

[Michael Snyder]

Phil Muldoon wrote:
> On 01/01/2010 08:01 AM, Joel Brobecker wrote:
>> 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.
> 
> Beyond the usual arguments and cons about CVS, the one thing that
> really bites is that CVS always has to talk to a remote server.  It is
> not distributed, so there is no local repository copy.  On a small
> project that is ok, but currently diffs with GDB CVS take 12-15
> minutes.  Commits are the same.  The same operations in GIT take
> seconds.  It is even worse in the US 8am - 6pm hours.  This might be
> because I live in the UK, and the server is on another continent.
> Maybe folks closer to the server get a snappier response.  But if
> there was problem that a distributed version control system was meant
> to fix, it was this.
> 
> I don't know why CVS is so slow.  Whether it is CPU bound on the
> sourceware machine, or the bandwidth at the hosting site is at
> capacity .. who knows?  I'm not even sure how to find out.  But would
> SVN solve any of the problem relating to performance?
> 
> My preference is for GIT, simply because of the speed.

FYI, my cvs operations are usually pretty snappy.
I live and work on the US west coast, and operate
during daylight hours.

time cvs -q update == 14 seconds for gdb "module" top level.

RE: time to be serious about dropping CVS

[Paul Koning]

There are lots of good reasons to get rid of CVS.  Its lack of
performance, its lack of atomicity, etc. etc.

Personally I'm a happy Subversion user.  I also observe that a closely
related large GNU project -- GCC -- uses Subversion.  So all things
being equal that's the one I would prefer.

Git I've used once or twice, really just for fetching current sources
for projects that use it.  That seemed to work ok.  It does seem to have
its collection of partisans.  Assuming that it too has the atomicity
properties that any real source control system has to have, that would
be an acceptable replacement as well.

Whatever is picked, I agree, it's time to get rid of that antique junk.

	paul

Re: time to be serious about dropping CVS

[Joseph S. Myers]

On Fri, 1 Jan 2010, Joel Brobecker wrote:

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

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.

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

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: time to be serious about dropping CVS

[Joel Brobecker]

> 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

Re: time to be serious about dropping CVS

[Jim Blandy]

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
>

Re: time to be serious about dropping CVS

[Pascal Obry]

Joël,

> 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:

Just to note that Git has support for partial checkout. Maybe this would
help transition. As it is a common misconception I'd like to mention
that Git support /partial checkout/ and NOT /partial fetch/. That is,
the whole repository is fetched and you can just checkout the part that
you want to work on. This is hardly a problem as the network support in
Git is very efficient.

-- 
  Pascal Obry
  --
  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: time to be serious about dropping CVS

[Tom Tromey]

>>>>> "Pascal" == Pascal Obry <obry@adacore.com> writes:

Pascal> Just to note that Git has support for partial checkout.

Nice -- new in 1.7:

http://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout

Pascal> As it is a common misconception I'd like to mention that Git
Pascal> support /partial checkout/ and NOT /partial fetch/. That is, the
Pascal> whole repository is fetched and you can just checkout the part
Pascal> that you want to work on. This is hardly a problem as the
Pascal> network support in Git is very efficient.

Perhaps some people will be concerned about the disk space.
(Though I am not.)

I looked through CVSROOT/modules a little.  I think it would be good if
we could split some of the modules off into their own repositories.
However, I don't know what in there is active or even what projects
would not mind being split off.

Tom

Re: time to be serious about dropping CVS

[Christopher Faylor]

On Tue, Dec 21, 2010 at 08:13:24AM -0700, Tom Tromey wrote:
>>>>>> "Pascal" == Pascal Obry <obry@adacore.com> writes:
>
>Pascal> Just to note that Git has support for partial checkout.
>
>Nice -- new in 1.7:
>
>http://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout
>
>Pascal> As it is a common misconception I'd like to mention that Git
>Pascal> support /partial checkout/ and NOT /partial fetch/. That is, the
>Pascal> whole repository is fetched and you can just checkout the part
>Pascal> that you want to work on. This is hardly a problem as the
>Pascal> network support in Git is very efficient.
>
>Perhaps some people will be concerned about the disk space.
>(Though I am not.)
>
>I looked through CVSROOT/modules a little.  I think it would be good if
>we could split some of the modules off into their own repositories.
>However, I don't know what in there is active or even what projects
>would not mind being split off.

As I've said before, I'd welcome splitting Cygwin into its own
repository and I would be interested in helping on the sourceware side.

cgf

Re: time to be serious about dropping CVS

[Joseph S. Myers]

On Tue, 21 Dec 2010, Christopher Faylor wrote:

> >I looked through CVSROOT/modules a little.  I think it would be good if
> >we could split some of the modules off into their own repositories.
> >However, I don't know what in there is active or even what projects
> >would not mind being split off.
> 
> As I've said before, I'd welcome splitting Cygwin into its own
> repository and I would be interested in helping on the sourceware side.

And I think that gdb+binutils (that is, the files and directories you get 
by checking out that module) should be split into its own repository - 
keep those two together, leave other projects to transition or not in 
their own time and their own way.  (The toplevel configure already 
supports --disable-<directory> generically, so with a combined source tree 
you can already use --disable-gdb --disable-sim --disable-readline to 
build binutils only, or --disable-binutils --disable-gas --disable-gprof 
--disable-ld --disable-gold to build GDB only - though simpler aliases 
might be useful.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: time to be serious about dropping CVS

[Tom Tromey]

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

Joseph> And I think that gdb+binutils (that is, the files and
Joseph> directories you get by checking out that module) should be split
Joseph> into its own repository - keep those two together, leave other
Joseph> projects to transition or not in their own time and their own
Joseph> way.

I agree binutils+gdb should be a single repository.  I didn't know about
the generic --disable-<directory> support; developers could either use
that or sparse checkouts, as they like.

Looking at CVSROOT/modules, I see a couple problem cases.

sid depends on BFD, and also includes cgen.

There is insight, which depends on gdb.

Tom

Re: time to be serious about dropping CVS

[Joseph S. Myers]

On Tue, 21 Dec 2010, Joel Brobecker wrote:

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

I don't think it ever was part of src in the sense of src being the master 
development repository for it - there simply used to be some imports of 
copies of it into the src repository.  Likewise tcl, tk, itcl still 
present on HEAD.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: time to be serious about dropping CVS

[DJ Delorie]

Just my two cents:

1. I really hate the way GIT works.  Yes, I use it often, no, I don't
   seem to be getting used to it.

2. If src/ is split up, keeping the toplevels and libiberty in sync will
   be much harder.  I don't think I'm willing to sign up for that job.

Re: time to be serious about dropping CVS

[Christopher Faylor]

On Tue, Dec 21, 2010 at 02:20:38PM -0500, DJ Delorie wrote:
>
>Just my two cents:
>
>1. I really hate the way GIT works.  Yes, I use it often, no, I don't
>   seem to be getting used to it.
>
>2. If src/ is split up, keeping the toplevels and libiberty in sync will
>   be much harder.  I don't think I'm willing to sign up for that job.

IMO, in a perfect world, there would be only one version of libiberty
and the top-level configury.

cgf

Re: time to be serious about dropping CVS

[NightStrike]

On Wed, Dec 22, 2010 at 10:23 AM, Christopher Faylor
<cgf-use-the-mailinglist-please@sourceware.org> wrote:
> On Tue, Dec 21, 2010 at 02:20:38PM -0500, DJ Delorie wrote:
>>
>>Just my two cents:
>>
>>1. I really hate the way GIT works.  Yes, I use it often, no, I don't
>>   seem to be getting used to it.
>>
>>2. If src/ is split up, keeping the toplevels and libiberty in sync will
>>   be much harder.  I don't think I'm willing to sign up for that job.
>
> IMO, in a perfect world, there would be only one version of libiberty
> and the top-level configury.
>
> cgf
>

That's easy to do with svn and svn:externals

Re: time to be serious about dropping CVS

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2978 bytes --]

On Wed, 22 Dec 2010, NightStrike wrote:

> On Wed, Dec 22, 2010 at 10:23 AM, Christopher Faylor
> <cgf-use-the-mailinglist-please@sourceware.org> wrote:
> > On Tue, Dec 21, 2010 at 02:20:38PM -0500, DJ Delorie wrote:
> >>
> >>Just my two cents:
> >>
> >>1. I really hate the way GIT works.  Yes, I use it often, no, I don't
> >>   seem to be getting used to it.
> >>
> >>2. If src/ is split up, keeping the toplevels and libiberty in sync will
> >>   be much harder.  I don't think I'm willing to sign up for that job.
> >
> > IMO, in a perfect world, there would be only one version of libiberty
> > and the top-level configury.
> >
> > cgf
> >
> 
> That's easy to do with svn and svn:externals

No solution I've ever seen suggested for this, including svn:externals and 
git submodules, counts as easy.  The basic requirements for being easy 
are:

* You can branch, or tag, GCC, or binutils, or GDB, or any other component 
including the library, using the native command for branching or tagging 
in that version control system, and thereby have a branch or tag wherein 
the affected subdirectories are also branched or tagged.  This applies to 
both remote branches and tags, and to local ones in a DVCS.

* Anyone with write access to any relevant component can do so, as well as 
being able to make ordinary changes to the library, and the normal 
commands for committing changes can be used, including for changes 
including both shared and non-shared files.

(I would add a further requirement "each project can choose its VCS 
independently", but that's not a matter of a solution being easy, it's a 
desire to avoid in future one of the two things that has made it so hard 
for the projects in src to move away from CVS.  One is tying independently 
maintained projects too closely together; the other is making use of a 
feature, CVS modules, that is too specific to a single VCS.)

When you get into special commands being needed to branch, tag or check in 
changes you get trouble and lose the advantages of familiarity with a VCS 
across multiple projects.  I think there are two sensible solutions for 
shared files:

* The DVCSly pure one: no master copy, people make changes in whichever 
project they are working on and they or someone else merges them to other 
copies as convenient.  This passes both my points above for being easy for 
normal contributors (at the expense of being hard for mergers).

* A single master repository for the shared files and directories, with 
all commits to those files in the trunk of the other repositories being 
forbidden by commit hooks unless they contain some magic string in the 
commit log to indicate they are merges from the master repository.  All 
people with write access to any affected project also given write access 
to this new master repository.  This passes my first point but fails the 
second.

-- 
Joseph S. Myers
joseph@codesourcery.com