[Ffmpeg-devel] SVN dump

[Michael Niedermayer]

Hi

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


> 
> 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.

thats what i feared, so in other words mercurial doesnt support it.
i of course can just checkin an old file again with any vcs but that kills
the history


> 
> > 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?


> 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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070428/1837c3f1/attachment.pgp>