tech-repository archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: The essential problems of moving from CVS
On 2010-01-12 10:16 +0100 (Tue), Martin Husemann wrote:
> I think you got it backward. The key qeustions are:
>
> - are there any options besides staying with cvs (for our repository,
> assuming we want to carry on all history "as good as possible")
Well, keep in mind we always have perfect history from the CVS archive.
Just because we switch doesn't mean that that's going to get deleted,
or anything like that. (It's not like the CVS reboot in the 90s, where
we had to ensure that the public did not have access to any of the
encumbered 4.4BSD sources in the old repository.)
So the real question you're posing is, do we need a *second* copy of the
perfect history in the new VCS. I posit that:
a) the "second perfect history" issue has a much, much smaller
impact on developers than does major changes to the NetBSD
development workflow,
b) the "second perfect history" issue is of lesser concern to the
majority of developers than NetBSD development workflow, and
c) many developers could be satisfied with the second copy of the
history being less than perfect in some ways.
> - are there any options besides staying with cvs (for our repository,
> assuming we want to carry on all history "as good as possible")
> - for each option, what consequences on the work flow would it have
If these are in order, it's backwards in my opinion. Figuring out how
good the history conversion will be, and whether or not we can live with
it, is a large task, involving a lot of lengthy testing and probably
some programming. Doing all that work for something where we know
there's a reasonable chance it would be rejected due to the different
workflow is extermely risky.
> Unfortunately so far (at least from my POV) the first question produced
> an empty list so the second was irrelevant.
Well, from my point of view that puts you in the group that believes
even if we could triple our development speed by switching, at the
cost of having one perfect historical record and a second 90%-perfect
historical record, that the second record can't be perfect means we
should bog down the project.
You're entitled to your opinion, but that's certainly not my thought on
the best balance of priorities.
> Next step would be to qualify the loss and see if
> we can live without or work around it.
1. How can you know if you can live with the loss if you don't know what
you're gaining in compensation?
2. The loss is variable, depending on how much effort we're willing to
put into the conversion.
cjs
--
Curt Sampson <cjs%cynic.net@localhost> +81 90 7737 2974
http://www.starling-software.com
The power of accurate observation is commonly called cynicism
by those who have not got it. --George Bernard Shaw
Home |
Main Index |
Thread Index |
Old Index