Re: GIT and CVS

Phil Muldoon
2011-10-13T20:55:12Z

"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