[Ffmpeg-devel] SVN dump

[Trent Piepho]

On Sat, 28 Apr 2007, Michael Niedermayer wrote:
> On Fri, Apr 27, 2007 at 11:17:19PM -0700, Trent Piepho wrote:
> > On Sat, 28 Apr 2007, Michael Niedermayer wrote:
> [...]
> > > 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.
>
> i know all that, what i tried was
> hg update 123
> hg cp fileA fileB
> hg ci fileB
> (hg up isnt possible here)
> hg merge 125 will update fileB to 125 of fileA which is plain wrong as fileB
> does not have a rev 125 differing from 123

hg copy doesn't do what one might expect, read this:
http://hgbook.red-bean.com/hgbookch5.html#x9-920005.3

hg update 123
cp fileA fileB
hg add fileB
hg commit -m "Added fileB"
hg merge 125
hg commit -m "merged with 125"

fileA will be updated to version 125, while fileB will remain as a copy of
what fileA was at revision 123.

> > > 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.
>
> but its never the same device, people would clone/pull from mphq ...
> so if they have a checkout of release X and head then they would end up
> with 2 completely seperate complete copies of the whole history or?

What you could do is clone the head from mphq, then clone that locally,
and then pull the release into the local copy.  That will only pull changes
in the release branch/repository that aren't in the head repository.

hg clone http://mqhq/hg/head
hg clone head release1
cd release1
hg pull -u http://mphq/hg/release1

> > It's easy to push, pull, and merge changes between
> > repositories (no different than moving changes between branches).
>
> really?
> if we have 2 repos
> first with change A, then change B and change C
> second with change D
>
> how do i merge change B without A and C) into the second repo, lets assume
> all changes are to seperate files ...
> i think i cannot cleanly that is i can only apply change B as if it where a
> independant change onto the second repo head

How would you pull out a change like this and commit it to a branch with
svn?

In mercurial, you can do this:

cd repo1
hg export 2 > ../repo2/b.patch
cd ../repo2
hg import b.patch && rm b.patch

Now repo2 will have just change B applied to it.

There is also the transplant extension for doing things like this:
http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension