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

[Michael Niedermayer]

Hi

On Wed, May 02, 2007 at 03:23:25AM -0700, Trent Piepho wrote:
> 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.

it depends on how you define problem, and of course on what is in the repo
what uoti talked about was randomizing a public branch before it would be
merged into the main branch, this is definitly not ok
deleting your sandbox repo which just contained a failed experiment is
a different issue ...


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

theres a small issue you seem to forget, ffmpeg does not follow the kernel
development model and noone even proposed to change to that, we currently
are just disscussing the possibility of switching to git or mercurial

we still would have a single main repository and everyone would have write
access to that and in that case problems _will_ happen as there are far
fewer steps involved, its just local commit + push and only a single person
sees the change before its in the main tree

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


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- 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/20070502/6889f9d1/attachment.pgp>