This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: What is keeping GDB in CVS ?
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