Janus Dam Nielsen <[EMAIL PROTECTED]> writes: >> The idea is the viff.dk will display the latest code and >> documentation whereas each release will contain a copy of the code >> and documentation as it was at the point of release. That way people >> should be able to always obtain API docs for their code, whether it >> being new or old. I would of course love if anybody thinks this is a >> bad idea... > > This is all great. You would probably also want to either fork the > repository or at least set some kind of marker (I don't know the > correct term) when a release is done.
It is called a "tag" in Mercurial, and I have already made some of those, please see: http://hg.viff.dk/viff/tags > In this way it is possible to go back and fix bugs in the release and > release that without upgrading or waiting to the next release. Yep, that is the (long-term) plan! If and when someone starts depending on us to keep the API stable, then we should definitely take care and fix the bugs as far back as they apply. So if we have a changeset graph like this A -> B -> C -> Rel1 -> D -> E -> Rel2 -> F -> G where Rel1 and Rel2 are the changesets tagged as releases and we discover that something is wrong in revision B, then one of us can update our repositories to the time of B: hg update -C B and commit a fix -- the "hg update" command is not just the way you get the latest changes into your working copy, it is the general command you issue to go back and forth in time. This makes the graph look like this: A -> B -> C -> Rel1 -> D -> E -> Rel2 -> F -> G \ Fix We will then want to merge the Fix head into the mainline. But we probably want to merge Fix and Rel1 to create Rel1.1: A -> B -> C -> Rel1 -> D -> E -> Rel2 -> F -> G \ \ Fix -> Rel1.1 And then Rel1.1 with Rel2 to make Rel2.2: A -> B -> C -> Rel1 -> D -> E -> Rel2 -> F -> G \ \ \ Fix ----> Rel1.1 ---------> Rel2.2 Finally we merge Rel2.2 into G: A -> B -> C -> Rel1 -> D -> E -> Rel2 -> F -> G -> Merge \ \ \ / Fix ----> Rel1.1 ---------> Rel2.2 ----------' I have never done something like this before, I have just read about it... So I might be wrong about a thing or two :-) Chapter 8 of the Mercurial Book contains more ideas for this: http://hgbook.red-bean.com/hgbookch8.html as does this Google Tech Talk: http://video.google.com/videoplay?docid=-577744660535947210 -- Martin Geisler
pgpvxSddSIOkJ.pgp
Description: PGP signature
_______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
