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

Trent Piepho xyzzy
Wed May 2 12:23:25 CEST 2007

On Wed, 2 May 2007, Michael Niedermayer wrote:
> > history; however those are mainly for private repositories and uses such
> > as integrating changes from one branch to another. "The official FFmpeg
> > git repository" should never have changes other than normal commits and
> > merges except in very special circumstances. If you have a separate
> > branch for developing a new feature then that could have its history
> > modified, erroneous commits removed etc before it's merged into the main
> > FFmpeg repository.
> i disagree of course, no public branch may be hacked it doesnt matter if
> its for new features or something else

Not branch, but repository.  Each developer has a number of repositories
that are basically personal sandboxes that come and go.  Take a look at the
list at http://linuxtv.org/hg/ Only the first two are the official
repositories.  I delete respositories I create all the time, and so do
other developers, and it's not a problem.

> let me explain a little bit why this is critically needed
> think of someone misstakely commiting the whole ffmpeg reindented or
> mistakely commiting a old ffmpeg version over the new
> or another total messup, these things do happen, and especially if
> they cannot be corrected and at the time where none of the developers
> is around

This happens much less often with non-SVN/CVS non-single repository
systems.  There are more than 53,000 commits in the Linux kernel
repository, and there are no disasters like that.  I'm not aware of the
repository ever needing to be hacked to delete a mistake.

It's not like svn, where once you push enter after "svn commit" it's a done
deal, no going back.  You don't have developers commit directly to the main
public repository.

For one of my patches to end up in the kernel, at a minimum:

I commit it to a local repository on my computer, and when I have a set of
changes I want to pass on or for others to see, I push from my computer to
one of my repositories on linuxtv.org.  When I want that to go into the
main branch, I write an email to Mauro and the v4l-dvb-developer's list
asking Mauro to pull.  I wrote an automated script to write the email,
which contains a list of patches that will be pulled and an overall
diffstat.  Mauro looks at the patches and the diffstat and (usually) pulls
into the main branch.  Based on the kernel development cycle, Mauro will
transfer the patches to git on kernel.org and send an email to Linus and
linux-kernel asking Linus to pull into main.  Linus then (usually) pulls
that batch of patches in.

If I commit some major mistake, there are many opportunities for me or
someone else to spot it before it's too late.  When I commit, hg will tell
me how many changes to how many files I just committed, I should notice if
that affects 1000 files instead of 1.  Mauro will notice if the diffstat
shows 10,000 lines changed.  Linus will notice if the git stats he looks at
aren't in line.

And if you do commit a big mistake to the main repository, you can always
send out a brown paper bag email and ask people to run "hg strip
1234deadbeef" to kill the mistake.  It's bad, but it's not the end of the
world.  I remember this happened once on linuxtv.org, when we also wanted
to update the reposistory to a newer storage format (which required a total
re-cloning), and it wasn't that big of a deal.

More information about the ffmpeg-devel mailing list