Here's my two units of your favorite currency:
>So, the very first thing to do is to setup the new hg repo.
>My only concern about that is the following?
>Should we convert the old CVS repo or it's enough to restart with an
>HEAD snapshot?
If importing the whole repository won't cause a problem on the CVS
server, I'd definitely recommend keeping it. I make a point of keeping
all my personal development under version control these days because
I've had too many experiences of wanting to figure out why I did
something a particular way several years ago, and not having any clue
because I don't have the version history (or perfect recall).
One suggestion I do have, if you take the full-repository route, is to
use Subversion as an intermediate stage--that is, convert the current
CVS to svn, and then convert that svn repository to hg. I've found
cvs2svn to work much better than hg convert on a CVS repository.
Along that line, I have a question: Do you want to try and use the
single-line-plus-multiple-line log message format suggested by the hg
developers or keep using ordinary log messages like we have with CVS?
The supposed advantage of single-plus-multiple is that it works well
with the non-verbose mode of hg log and similar commands, but I'd argue
very strongly for the latter (ordinary log messages), because
(1) the former is a DRY(*) violation,
(2) our commit messages tend to be concise anyway (making the
single-plus-multiple form even more repetitive), and
(3) it's not worth it just to squeeze more lines into a page.
With respect to (3) in particular, in the half year or so I've been
using hg for my previously-mentioned personal project, I've never once
felt the need to use the short form of log or similar commands--in fact,
my ~/.hgrc has -v for the log/tip/heads/outgoing default options.
(*) Don't Repeat Yourself
>Once solved the repo thing, here it is the roadmap to 1.2.0.
[... skipping things I agree with ...]
>* Deep review of tcframe*: in a nutshell: refactoring. Made possible by
> new framebuffer (cfr past thread) in transcode-legacy _AND_ into
> transcode-future. Anyway, this not on my short term TODO.
Agreed this probably shouldn't be on the immediate-future list. That
said, we should try to at least get it stable on HEAD, so it doesn't get
in the way of everything else we do. (:
>* NMS-compliant export layer. This also mean dropping (aka: hg rm...)
> the OMS layer. Only preset cfg file will survive into export/.
> This also mean *A LOT* of testing too and very likely minor changes
> (proper extradata, PTS handling). Bonus point: export profiles became
> working.
That looks good, but I've been wondering about the import side as well.
I'm trying to remember whether we ever ran into problems implementing
the decode stage in NMS, or if we just hadn't gotten that far yet.
>Plus, a new topic:
>
>* switch to graphicksmagic (http://www.graphicsmagick.org/)
Good find! I have no argument with that whatsoever. (:
--Andrew Church
achu...@achurch.org
http://achurch.org/
