[FFmpeg-devel] [Ffmpeg-devel] SVN dump

[Trent Piepho]

On Wed, 2 May 2007, Andy Parkins wrote:
> On Wednesday 2007 May 02, Michael Niedermayer wrote:
> > because of that we need to be able to fix mistakes and sending everyone a
> > mail saying "hg strip 1234deadbeef" is not an option. thats even more
> > primitive than cvs
>
> I'm curious - what is the procedure now to undo a commit in subversion?
>
>  * -- * -- * -- * -- B -- * -- * -- *
>
> How do you get rid of B without damaging the subsequent commits?

How do you do this in CVS?  The only way I know is to use cvs admin -o to
obsolete B, and then tell everyone to delete the affected files and
re-update.

> The reason revision editing is a problem is that every commit is dependendent
> on all the previous commits; so while you _can_ remove a commit and replace
> the subsequent commits, you get a situation like this:
>
>  * -- * -- * -- * -- B -- 1 -- 2 -- 3
>                  \
>                   1' -- 2' -- 3'
>

The same in Mercurial.  After doing this fix, the master has two heads, 3 and
3'.  If you don't want this, and don't want B to physically be stored anymore,
you would run on the master repro 'hg strip B'.  That would kill the B-1-2-3
branch, remove the "3" head and leave just the "3'" head.

People who pulled "B" while it existed will still have it in their copies of
the repository.  So what?  Since 3' is newer, it will be the new tip.  There
is nothing wrong with their repo, it just has an extra mistake branch in it.
If they are bothered by this banch being listed with 'hg heads' or seeing 'B'
in 'hg log', they can just delete the branch with 'hg strip B'.

> Then, people who grabbed 1, 2 or 3 will be basing their new revisions off of
> them, rather than off of the replacements 1', 2', or 3'.  When they try to
> send those updates to the central repository they'll get error messages about
> not being able to update a non-fast-forward reference.

If a developer based a patch off of 3 instead of 3', they will have to
re-create their patch based off the new tip.  I think it's important to point
out that SVN doesn't handle this at all!

Say someone re-indented SVN, and then I based a patch off of this re-intended
repro.  Michael kills the re-intention using his copy method.  Can he pull my
patch without problems from my svn repository into the master svn?  Of course
not, because svn doesn't even support the concept of multiple repositories!

If I email the patch to the list, since the entire repo was re-indented, it
will be nothing but conflicts.  I'll have to re-create the patch based on the
fixed svn, just like with Mercurial/git.

> Now imagine this, instead of committing on top of the existing revisions, I
> rewind my branch pointer and start committing on an earlier revision:
>
>   1 --- 2 --- 3 (up/master)        DEVELOPER REPO
>          \
>           4 -- 5 (mymaster)

The common way this happens is that '2' was the latest patch when you started
working and commited 4.  But before you push into the main repository, someone
else commited 3.  When you have lots of developers, there really is no way to
avoid this.  During a kernel two week merge window, there will thousands of
commits authored by hundreds of developers.  They couldn't possibly all take
turns!