What is keeping GDB in CVS ?

What is keeping GDB in CVS ?

[Samuel Bronson]

Hi. I'm wondering what the reasons are that GDB is still using CVS.
In other words: what work must be done in order for it to be possible
to switch it over to Git or Bzr?

Re: What is keeping GDB in CVS ?

[Daniel Jacobowitz]

On Fri, Jun 19, 2009 at 12:13:31PM -0400, Samuel Bronson wrote:
> Hi. I'm wondering what the reasons are that GDB is still using CVS.
> In other words: what work must be done in order for it to be possible
> to switch it over to Git or Bzr?

Two things.  One is a compelling reason to switch.  (This is not an
invitation; there's plenty of discussion of this in the archives.
Personally I'd be happy to switch, but I'm easy to convince plus
having it in CVS is a real nuisance for me.)

The other thing is the combined src repository, which is shared
between many projects including binutils, newlib, cgen, and gdb.  I
think we need to either decide to split them up and manage the shared
directories specially, or come up with a clever way to fake
CVS-style modules.  Or else give up and make people check out the
whole thing, which might drive projects out into a new repository
anyway; a src checkout is bigger than anyone needs.

There was another discussion of this on the binutils list recently.

http://sourceware.org/ml/binutils/2009-05/msg00028.html

-- 
Daniel Jacobowitz
CodeSourcery

Re: What is keeping GDB in CVS ?

[Daniel Jacobowitz]

On Fri, Jun 19, 2009 at 12:23:08PM -0400, Daniel Jacobowitz wrote:
> There was another discussion of this on the binutils list recently.
> 
> http://sourceware.org/ml/binutils/2009-05/msg00028.html

FWIW, the discussion got stuck, but the most promising leaf was this
message from Joel, I think:

http://sourceware.org/ml/binutils/2009-05/msg00176.html

-- 
Daniel Jacobowitz
CodeSourcery

Re: What is keeping GDB in CVS ?

[Christopher Faylor]

On Fri, Jun 19, 2009 at 12:28:01PM -0400, Daniel Jacobowitz wrote:
>On Fri, Jun 19, 2009 at 12:23:08PM -0400, Daniel Jacobowitz wrote:
>> There was another discussion of this on the binutils list recently.
>> 
>> http://sourceware.org/ml/binutils/2009-05/msg00028.html
>
>FWIW, the discussion got stuck, but the most promising leaf was this
>message from Joel, I think:
>
>http://sourceware.org/ml/binutils/2009-05/msg00176.html

I still think that the various projects merged under the "src" umbrella
should be pulled apart and given their own repositories.  There is
really, for instance, no reason for Cygwin or cgen, which are non-FSF
projects, to be intermingled with gdb and binutils.

However, I am very sympathetic to the notion that "It ain't broke..."

cgf

Re: What is keeping GDB in CVS ?

[Daniel Jacobowitz]

On Fri, Jun 19, 2009 at 12:37:53PM -0400, Christopher Faylor wrote:
> I still think that the various projects merged under the "src" umbrella
> should be pulled apart and given their own repositories.  There is
> really, for instance, no reason for Cygwin or cgen, which are non-FSF
> projects, to be intermingled with gdb and binutils.
> 
> However, I am very sympathetic to the notion that "It ain't broke..."

The solution I'd like best, I think, is one with separate projects
that makes it easy to manually or automatically sync revisions from
the shared directories.  This may be nothing more than some clever
push hooks, for instance to reject manual changes to bfd/ being pushed
to the central gdb repository and to automatically propogate changes
to bfd/ from binutils.  Anyone feeling inspired enough to build a
proof-of-concept?

-- 
Daniel Jacobowitz
CodeSourcery

Re: What is keeping GDB in CVS ?

[Richard Earnshaw]

On Fri, 2009-06-19 at 12:49 -0400, Daniel Jacobowitz wrote:
> On Fri, Jun 19, 2009 at 12:37:53PM -0400, Christopher Faylor wrote:
> > I still think that the various projects merged under the "src" umbrella
> > should be pulled apart and given their own repositories.  There is
> > really, for instance, no reason for Cygwin or cgen, which are non-FSF
> > projects, to be intermingled with gdb and binutils.
> > 
> > However, I am very sympathetic to the notion that "It ain't broke..."
> 
> The solution I'd like best, I think, is one with separate projects
> that makes it easy to manually or automatically sync revisions from
> the shared directories.  This may be nothing more than some clever
> push hooks, for instance to reject manual changes to bfd/ being pushed
> to the central gdb repository and to automatically propogate changes
> to bfd/ from binutils.  Anyone feeling inspired enough to build a
> proof-of-concept?
> 
As someone who builds complete cross toolchains on a regular basis, I'd
prefer for things not to become too fragmented.  My preferred split
would be for those tools that share source infrastructure to remain
combined (binutils/gas/gdb) and maybe split out the others.  It would be
a right royal pain to have to edit three copies of an identical file
when developing and testing -- it's bad enough having gcc outside of the
infrastructure.

R.

Re: What is keeping GDB in CVS ?

[Joseph S. Myers]

On Fri, 19 Jun 2009, Christopher Faylor wrote:

> I still think that the various projects merged under the "src" umbrella
> should be pulled apart and given their own repositories.  There is
> really, for instance, no reason for Cygwin or cgen, which are non-FSF
> projects, to be intermingled with gdb and binutils.

The cpu directory, however, does need including in binutils checkouts 
because it provides the source code to generated files there, even if it 
might otherwise be seen as part of cgen.  (I agree regarding Cygwin; 
likewise the copies of tcl and tk that are still present in src 
checkouts.)

However, we have so far been unable to keep shared files reliably in sync 
between gcc and src.  The following files should be identical, but aren't 
right now.

Makefile.def
Makefile.in
Makefile.tpl
configure
configure.ac
config/ChangeLog
config/lead-dot.m4
config/mh-cygwin
config/tls.m4
config/unwind_ipinfo.m4
config/warnings.m4
include/ChangeLog-9103

I would suggest that before working out systems involving much more 
synchronization of shared files between repositories, we establish a 
system that works reliably for the existing shared directories, 
disallowing manual commits in whichever is declared not to be the master.  
The non-shared toplevel ChangeLog and include/ChangeLog may complicate 
things a bit (I'd suggest renaming the existing toplevel ChangeLogs and 
putting only changes to shared files in a new shared toplevel ChangeLog, 
and likewise include/), as may the existence of files in include/ that are 
only in src not in GCC.  Any system involving splitting up src then needs 
to have similar automatic synchronization.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: What is keeping GDB in CVS ?

[Daniel Jacobowitz]

On Fri, Jun 19, 2009 at 05:56:27PM +0100, Richard Earnshaw wrote:
> As someone who builds complete cross toolchains on a regular basis, I'd
> prefer for things not to become too fragmented.  My preferred split
> would be for those tools that share source infrastructure to remain
> combined (binutils/gas/gdb) and maybe split out the others.  It would be
> a right royal pain to have to edit three copies of an identical file
> when developing and testing -- it's bad enough having gcc outside of the
> infrastructure.

FWIW, I see this as a problem we could solve with scripts and/or docs;
I've done this using symlinks to binutils plenty of times.

-- 
Daniel Jacobowitz
CodeSourcery

Re: What is keeping GDB in CVS ?

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> The solution I'd like best, I think, is one with separate projects
Daniel> that makes it easy to manually or automatically sync revisions from
Daniel> the shared directories.  This may be nothing more than some clever
Daniel> push hooks, for instance to reject manual changes to bfd/ being pushed
Daniel> to the central gdb repository and to automatically propogate changes
Daniel> to bfd/ from binutils.  Anyone feeling inspired enough to build a
Daniel> proof-of-concept?

I meant to reply again on the binutils thread, but I'm super
distracted these days.

I researched it a bit and I believe that git doesn't provide a nice
way to solve the modules problem.  There are a couple promising
approaches but I think if you look closely they don't really work (in
one case the exact feature we need was never merged into git).

One idea I had is to have an "infrastructure" repository holding
top-level configure, plus libiberty and include.  Then, gcc, src,
cgen, cygwin, etc would simply merge from this repository.  And, we'd
have a rule: no local changes.

These kinds of merges are trivial, we do them all the time in archer
(archer's master branch tracks gdb's master branch this way).  You
could even automate them, if the no local change rule was enforced.

Finally, I think binutils+gdb should probably just be a single source
repository.  They share enough to warrant that, IMO.  I suspect the
disk space overhead is not large.

I have no idea what to do about insight.

The problem with this approach is that it is less convenient than what
we have now.  If you have a change that touches libiberty then you
need two separate commits.

I suppose this is basically what you're saying :-)

I guess some new version of svn solves the module problem.
But... after working with git for the last year, I used svn for a gcc
patch this week and I was surprised by how amazingly slow it now
feels.  I'd really prefer git by a large margin.

Tom

Re: What is keeping GDB in CVS ?

[Joseph S. Myers]

On Fri, 19 Jun 2009, Tom Tromey wrote:

> One idea I had is to have an "infrastructure" repository holding
> top-level configure, plus libiberty and include.  Then, gcc, src,
> cgen, cygwin, etc would simply merge from this repository.  And, we'd
> have a rule: no local changes.

That's no local changes to these files on the development mainline of all 
but the one repository.  Release branches still need to be able to have 
changes to them.

If the separate repositories solution is chosen, it is not necessary for 
all projects to convert at once, or even to convert to the same system; 
having set up the infrastructure arrangements (and I think GCC as master 
for those files would work just as well as a separate repository) 
individual projects could move away from CVS (disallowing HEAD commits on 
their parts of the CVS repository) when convenient to them.  For example, 
if we still wish to integrate the older binutils and GDB history when 
converting those projects, other projects would not need to wait for that 
history to be made available.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: What is keeping GDB in CVS ?

[Christopher Faylor]

On Fri, Jun 19, 2009 at 05:17:54PM +0000, Joseph S. Myers wrote:
>On Fri, 19 Jun 2009, Christopher Faylor wrote:
>>I still think that the various projects merged under the "src" umbrella
>>should be pulled apart and given their own repositories.  There is
>>really, for instance, no reason for Cygwin or cgen, which are non-FSF
>>projects, to be intermingled with gdb and binutils.
>
>The cpu directory, however, does need including in binutils checkouts
>because it provides the source code to generated files there, even if
>it might otherwise be seen as part of cgen.  (I agree regarding Cygwin;
>likewise the copies of tcl and tk that are still present in src
>checkouts.)
>
>However, we have so far been unable to keep shared files reliably in
>sync between gcc and src.  The following files should be identical, but
>aren't right now.
>
>Makefile.def Makefile.in Makefile.tpl configure configure.ac
>config/ChangeLog config/lead-dot.m4 config/mh-cygwin config/tls.m4
>config/unwind_ipinfo.m4 config/warnings.m4 include/ChangeLog-9103

So maybe they shouldn't be *shared*.  There could be just one copy.  I
think everyone knows that you'll have problems as soon as you start
duplicating data.  This is no exception.

I doubt that the gcc project would think it was a good idea but we could
just break libiberty and the top-level configury into a separate
repository too.  Then when you make a change to a file, everyone gets
the change and people will squawk immediately when you make a change to
one of these files for gcc which happens to break a binutils build.

cgf

Re: What is keeping GDB in CVS ?

[Joseph S. Myers]

On Fri, 19 Jun 2009, Christopher Faylor wrote:

> So maybe they shouldn't be *shared*.  There could be just one copy.  I
> think everyone knows that you'll have problems as soon as you start
> duplicating data.  This is no exception.
> 
> I doubt that the gcc project would think it was a good idea but we could
> just break libiberty and the top-level configury into a separate
> repository too.  Then when you make a change to a file, everyone gets
> the change and people will squawk immediately when you make a change to
> one of these files for gcc which happens to break a binutils build.

That worked for the old GNU hardlinks-to-,v-files approach.  I don't think 
it's effectively supported by any version control system more modern than 
CVS.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: What is keeping GDB in CVS ?

[Christopher Faylor]

On Fri, Jun 19, 2009 at 07:29:18PM +0000, Joseph S. Myers wrote:
>On Fri, 19 Jun 2009, Christopher Faylor wrote:
>>So maybe they shouldn't be *shared*.  There could be just one copy.  I
>>think everyone knows that you'll have problems as soon as you start
>>duplicating data.  This is no exception.
>>
>>I doubt that the gcc project would think it was a good idea but we
>>could just break libiberty and the top-level configury into a separate
>>repository too.  Then when you make a change to a file, everyone gets
>>the change and people will squawk immediately when you make a change to
>>one of these files for gcc which happens to break a binutils build.
>
>That worked for the old GNU hardlinks-to-,v-files approach.  I don't
>think it's effectively supported by any version control system more
>modern than CVS.

You're reading more into what I wrote than I intended.  I wasn't
proposing any trickery.  I'm just saying that, IMO, if a group of files
is shared between projects the shared group of files should be stored in
their own repository.

I haven't used git so maybe it adds extra wrinkles but I can't see how
it would be THAT hard to accommodate keeping things in separate
directories.  You can either use symlinks, or, 'source' lines in shell
scripts and 'include' lines in Makefiles.

I don't buy the complaining that this would cause terrible consequences
for someone's established workflow.  We're talking about programmers
here.  If they can't adapt to a change like this then it's hard to see
how they could be contributing much to any of these projects.

cgf

Re: What is keeping GDB in CVS ?

[Joseph S. Myers]

On Sat, 20 Jun 2009, Christopher Faylor wrote:

> You're reading more into what I wrote than I intended.  I wasn't
> proposing any trickery.  I'm just saying that, IMO, if a group of files
> is shared between projects the shared group of files should be stored in
> their own repository.
> 
> I haven't used git so maybe it adds extra wrinkles but I can't see how
> it would be THAT hard to accommodate keeping things in separate
> directories.  You can either use symlinks, or, 'source' lines in shell
> scripts and 'include' lines in Makefiles.

It seems quite clear to me that all these files should be automatically 
tagged when the projects using them are tagged and branched when those 
projects are branched and the tagged or branched versions should be 
checked out automatically when the tag or branch is checked out.  You can 
of course invent systems for tagging or branching in multiple 
repositories, but if you require people to do something that's not the 
normal way of using whatever version control system is used then trouble 
will inevitably result (cf. the present issues with not being able to use 
"cvs update -d" as normal in the present arrangements).  As I said in the 
binutils discussion, version control systems should make common tasks easy 
and mistakes in common tasks difficult.  (This suggests allowing commits 
to the shared files anywhere and automatically merging everywhere else 
behind the scenes as the friendliest arrangement even if harder to 
implement.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: What is keeping GDB in CVS ?

[Christopher Faylor]

On Sat, Jun 20, 2009 at 07:19:46PM +0000, Joseph S. Myers wrote:
>On Sat, 20 Jun 2009, Christopher Faylor wrote:
>>You're reading more into what I wrote than I intended.  I wasn't
>>proposing any trickery.  I'm just saying that, IMO, if a group of files
>>is shared between projects the shared group of files should be stored
>>in their own repository.
>>
>>I haven't used git so maybe it adds extra wrinkles but I can't see how
>>it would be THAT hard to accommodate keeping things in separate
>>directories.  You can either use symlinks, or, 'source' lines in shell
>>scripts and 'include' lines in Makefiles.
>
>It seems quite clear to me that all these files should be automatically
>tagged when the projects using them are tagged and branched when those
>projects are branched and the tagged or branched versions should be
>checked out automatically when the tag or branch is checked out.  You
>can of course invent systems for tagging or branching in multiple
>repositories, but if you require people to do something that's not the
>normal way of using whatever version control system is used then
>trouble will inevitably result (cf.  the present issues with not being
>able to use "cvs update -d" as normal in the present arrangements).  As
>I said in the binutils discussion, version control systems should make
>common tasks easy and mistakes in common tasks difficult.  (This
>suggests allowing commits to the shared files anywhere and
>automatically merging everywhere else behind the scenes as the
>friendliest arrangement even if harder to implement.)

If you add a "create-branch" script to the config repository and make it
clear that this is the only accepted method for creating a branch then,
IMO, that should be adequate.  That wouldn't help if some random git
expert wanders into the project and decides to start branching without
figuring out best practice for the project but I don't think we have to
care about people like that.

cgf

Re: What is keeping GDB in CVS ?

[Jan Kratochvil]

On Sat, 20 Jun 2009 21:19:46 +0200, Joseph S. Myers wrote:
> You can of course invent systems for tagging or branching in multiple
> repositories,

Google Android is using their own `Repo' to manage many git subrepositories:
	http://source.android.com/download/using-repo

I do not have serious experience with it to refer more.


Regards,
Jan

Re: What is keeping GDB in CVS ?

[Tom Tromey]

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

Joseph> It seems quite clear to me that all these files should be automatically 
Joseph> tagged when the projects using them are tagged and branched when those 
Joseph> projects are branched and the tagged or branched versions should be 
Joseph> checked out automatically when the tag or branch is checked out.

I looked into the situation a bit more.

My understanding is that the git "submodules" feature only works for
subdirectories of the tree.  It would not therefore work directly for
'src', due to the top-level configury.  It could be made to work, by
requiring some pre-configure command to make symlinks or shuffle files
around.

I still think the best approach is to have a single "infra" repository
holding the shared bits, which is then merged as-needed into other
repositories.  But, there are even issues with this.  One is, what
history do we use to initially populate this repository?  (Maybe it
doesn't matter due to all the double commits.)  The other is, this
would require changes to how gcc handles this code; and since gcc uses
svn I suppose (but don't know for sure) that it would be a pain.

I haven't looked into the "repo" tool that Jan mentioned, yet.

Tom

Re: What is keeping GDB in CVS ?

[Daniel Jacobowitz]

On Thu, Jun 25, 2009 at 03:42:45PM -0600, Tom Tromey wrote:
> I haven't looked into the "repo" tool that Jan mentioned, yet.

It didn't look to me like it would help.

I like the idea of separate repositories for shared code.  It
still leaves us needing some tricky scripts to keep our version
control system working, but it lets us put them where developers don't
need to run them.

-- 
Daniel Jacobowitz
CodeSourcery