This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A couple more subversion notes
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rasky at develer dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 20 Oct 05 11:29:33 EDT
- Subject: Re: A couple more subversion notes
Less often than needed or wanted, because it takes way too much time
to do one, instead of few seconds as it should. One may want to merge
a development branch every day or so, but it can't be done right now
because the overhead of the operation is too high. This causes people
to batch merges in big drops, which increase the conflicts and the
time to solve those (when something does not work, you have to
investigate a larger timespan to find out what broken what, and you
have to do that without even seeing atomic changesets in logs).
Is the actual time of doing the merge itself the dominating factor?
Even if it were done every day, I'd expect some conflicts and things
not working. You certainly have to include testing time in the merge
time. I'm skeptical that the actual merge rate of branches would
increase much.
Notice that large merge commits on branches lock the whole CVS
repository for everybody for long time.
That is indeed an issue.