Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <joseph@codesourcery.com>
To: gdb@sourceware.org
Subject: Re: What is keeping GDB in CVS ?
Date: Sat, 20 Jun 2009 19:19:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.0906201913080.16849@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20090620184837.GA866@ednor.casa.cgf.cx>

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


  reply	other threads:[~2009-06-20 19:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-19 16:13 Samuel Bronson
2009-06-19 16:23 ` Daniel Jacobowitz
2009-06-19 16:28   ` Daniel Jacobowitz
2009-06-19 16:38     ` Christopher Faylor
2009-06-19 16:49       ` Daniel Jacobowitz
2009-06-19 16:56         ` Richard Earnshaw
2009-06-19 17:28           ` Daniel Jacobowitz
2009-06-19 17:30         ` Tom Tromey
2009-06-19 19:18           ` Joseph S. Myers
2009-06-19 17:18       ` Joseph S. Myers
2009-06-19 19:22         ` Christopher Faylor
2009-06-19 19:29           ` Joseph S. Myers
2009-06-20 18:48             ` Christopher Faylor
2009-06-20 19:19               ` Joseph S. Myers [this message]
2009-06-20 20:36                 ` Christopher Faylor
2009-06-20 20:53                 ` Jan Kratochvil
2009-06-25 21:45                 ` Tom Tromey
2009-06-26 12:28                   ` Daniel Jacobowitz

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=Pine.LNX.4.64.0906201913080.16849@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=gdb@sourceware.org \
    /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