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

[Uoti Urpala]

On Wed, 2007-05-02 at 10:42 +0200, Michael Niedermayer wrote:
> > 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

Depends on what kind of public branch. If you have a publicly available
development branch specific to one new feature, which is intended to be
abandoned once the feature is merged to the main branch, then modifying
its history before merging can make sense. This probably doesn't mean
modifying the public version (that would be pretty pointless) but
modifying it locally before merging it to the main one, so that the
merged history in the main repository differs from the original.

> > branch. However if the old branch was public then people will get
> > problems and will be annoyed when you abandon it and start a new one
> > instead (they could also have not-(yet-)-merged changes on top of the
> > old branch etc...).
> 
> all they have to do is
> git checkout -m new_branch
> or?

git does not download all remote branches by default, so you wouldn't
have new_branch there automatically. So first you'd need to get the new
remote branch. "-m" is for "local modifications" only in the sense of
changes which aren't committed to any branch; local changes can also be
kept as commits on top of the previous history. How those would need to
be handled would depend on the exact nature of the commits. In the best
case it would be a single rebase command, but it could get more complex.

> and anyway this is critical, if this cant be done (compared to you just
> dont like it) then i will not agree to switch ffmpeg to git

Well that's a matter of definition. You "can" do it, like you "can"
rebuild the repository daily with svn or switch to a different version
control system every few days. It's possible to create a new repository
with changed history; but existing checkouts cannot simply update to the
new repository, and it does waste significant amounts of people's time.

> 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
> 
> simply deleting the latest revission will break checkouts it also
> changes history which isnt good
> simply reverting the change with a new commit will wipe out the history
> as shown with annotate

I don't consider annotate of last version showing the revert to be so
bad that a workaround would be "critically needed". git also has tools
to find relevant changes that are completely missing in svn, such as
"git log -Sstring file/dir" to find all changes which add or remove
"string". No matter what hacks you play with "svn cp" you won't get that
working _at all_ in svn. I consider that more important that what
annotate shows for reverted parts.


A note about the way git views history:
Commits in git do not indicate what changed from the previous version,
only what the new state of the complete repository is. Creating a diff
is left completely to the frontend which wants to show one. That holds
for line changes (whether "AB"->"BA" is deleting A and adding one at the
end, or deleting B and adding one at the beginning) and for file-level
operations (whether files are copied or created from scratch etc). I
personally think this can be suboptimal for file/directory moves
sometimes, but probably doesn't cause problems too often.

The main parts in a git commit are
1) A commit message and timestamp
2) Complete file paths/contents/modes of the repository, basically
everything determining what a checkout of this single revision looks
like
3) A list of references to "parent" commits. A normal single commit has
one parent (the previous HEAD of the branch when the commit was made),
merges can have several.

And that's all that is stored in the history. How to interpret the
history for things such as "annotate" is completely up to the frontend
used.