This is the mail archive of the
mailing list for the GDB project.
Re: GIT and CVS
"Joseph S. Myers" <email@example.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
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?