This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GIT and CVS


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

> On Thu, 13 Oct 2011, Phil Muldoon wrote:
>
>> So why are we still on CVS?  I'm not a release manager, so I do not have
>
> Because the complications associated with having many projects in the same 
> repository are a lot of work to disentangle, and it is a lot of work to do 
> the conversion (including all the infrastructure scripts, user 
> instructions etc.) for any one project.
>
> I think binutils+gdb is the right unit to aim for getting into a separate 
> repository, as discussed in 
> <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>.

Ok, thanks for your response.  Beyond the reason why they were in the
same repository for how many years, why do they still have to be?

I can understand that projects so closely involved need to be in
lock-step in their release objectives, but with healthy communities for
each project, do they need to be still?

I think though, I am missing the point.  If GDB decides, on its own, to
go with GIT, what happens to the other projects?  What are the outcomes?
I just do not understand why this is a problem, and I wish somebody
could just tell me the problems.  Can they continue on CVS without harm?
Could we persuade them about GIT too? Is it a problem with long CVS
history? What are the problems here?

I hack on GDB, and I really don't hack on much else.  This is not to
diminish other projects, I just don't hack on them.  While other modules
represented by other projects are important, I am trying to understand
the reason why this is a blocker?  Building GDB requires a lot of
dependencies outside of what is provided in the repository.

> ChangeLogs are very useful whatever the version control system; it's 
> routine to import snapshots from one system into another and the 
> ChangeLogs are readily available to see what source version you actually 
> have there.  ChangeLogs are convenient to grep and much less I/O intensive 
> than git operations are (especially when your checkout is on NFS).

I nearly decided to delete that line from the email as I did not want to
dilute the arguments.  I wrote the ChangeLog parser for Eclipse as I found
ChangeLogs tiresome to write when history basically replaced it.  I must
admit, even when I hack on emacs, it is still a pain.  I'll continue to
do it, if people find it useful.  However, git log is very, highly
configurable.  The options are very broad.  And, as you can generate a
git log from a local repository, the NFS thing should not be too
difficult to overcome?

Cheers,

Phil


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]