[Ffmpeg-devel] SVN dump

[Trent Piepho]

On Sat, 28 Apr 2007, Michael Niedermayer wrote:
> On Fri, Apr 27, 2007 at 11:58:51PM +0200, Aurelien Jacobs wrote:
> > I'm not a CVS expert so I don't know what you mean concerning it's
> > rollbacks limitations.
> > Still, here is a simple explanation about HG rollbacks.
> >
> > Mercurial is based on the principle that history is immutable. So you
> > can't remove revisions, you can only add new revisions.

That is not entirely true anymore.  Mercurial has since one of the 0.9x
versions had a strip command.  This will let you remove the last X
revisions from the repository.  This is sort of like hacking the repo, and
will cause problems if other people have pulled the stripped revisions from
the repository.  It's useful for developers to fix patches they have
already comitted to their repositories before they get pulled into the main
repository.

There is also a rollback command, which commits a new changeset that undoes
a previous changeset.

> what i would like (i of course dont know if that matches what nico wants)
> is that i can take revision X of file Y and copy that to a new file or
> replace the head version of the old file by it, and that
> annotate/log will show the true history that is without the revissions
> which are not part of that branch or alternatively clearly seperate the
> revissions which arent part of the file

I'm not sure I understand what you're trying to do.

The hg update command updates the entire working directory to a given
revision (default is to the head aka tip revision).  Mercurial
isn't like CVS where one file can be at revision X and another file
at revision Y.

If you run 'hg update 1234', and then do a 'hg commit', the new changeset
you commit will have rev 1234 as it's parent.  If 1234 isn't the tip, then
you will create a new branch.

If you want to change the contents of just one file to an older version,
you can use the hg revert command, which lets you specify a revision to
revert to and the files to revert.

hg update 1234 ; hg revert -r 1000 somefile.c

That will update working directory to rev 1234.  'hg parents' will report
the working directory is based on rev 1234.  If you commit, the new
changeset's parent will be 1234.  The contents of somefile.c will be the
same as it was in rev 1000.  somefile.c parent is still rev 1234, not 1000.
It's no different than if you had changed somefile.c with a text editor.

> if there is no way to branch past revissions properly then mercurial is out
> of question for me for ffmpeg
> but i hope that iam just too stupid to use mercurial, after all with that
> limitation we couldnt even branch a release off in the same repository
> but rather would have to create anew repository for that which is idiotic

I think the newest development versions of Mercurial let you name branches,
like git can do.

Having multiple repositories isn't so bad though.  cloning on the same
device is done with hard links and so new repositories don't take up much
extra space.  It's easy to push, pull, and merge changes between
repositories (no different than moving changes between branches).