On Tue, 2009-01-20 at 05:47 +0000, Andrew Church wrote: > 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.
Sounds sensible, I'll go this way. > 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? [...] My very first idea, yet susceptible to changes (I haven't yet read enough about hg ;)) is to *try* to write log messages like we already have in CVS, but in a way that the very first line summarize the whole thing. e.g. (line number/actual text) commit message of somefile.c: 1 rewrote the whole thing. 2 because the old one sucked in a bunch of ways: 3 1) blahblah blah 4 2) yadda yadda... If that's not feasible or just forgotten, I'll get stuck on the old CVS way. The reasons are so far the ones you pointed out. > 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. Just lack of time. We spotted a few problems some time ago 1) lack of explicit open/close methods 2) *need* for the demuxer to deliver full encoded frames payload, not packets (thinking to MPEG) But all of them should be solvable with minimal changes to current API. +++ Moreover: we need an official GUI. I suck really bad in doing GUIs, so I'll just start gathering ideas. Will not happen soon (not in 1.2.0 timeframe). Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
