[FFmpeg-devel] [PATCH] Documentation updates for the git migration

Janne Grunau janne-ffmpeg
Mon Feb 7 19:30:43 CET 2011


On Mon, Feb 07, 2011 at 07:08:04PM +0100, Reinhard Tartler wrote:
> This cleanup patch updates the developer documentation to refer to the
> new location of the git repository.
> ---
>  doc/TODO             |    2 +-
>  doc/developer.texi   |    6 +++---
>  doc/optimization.txt |    4 ++--
>  doc/soc.txt          |    4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/doc/TODO b/doc/TODO
> index 747eee4..f3b99a2 100644
> --- a/doc/TODO
> +++ b/doc/TODO
> @@ -69,7 +69,7 @@ unassigned TODO: (unordered)
>  - JPEG2000 decoder & encoder
>  - MPEG4 GMC encoding support
>  - macroblock based pixel format (better cache locality, somewhat complex, one paper claimed it faster for high res)
> -- regression tests for codecs which do not have an encoder (I+P-frame bitstream in svn)
> +- regression tests for codecs which do not have an encoder (I+P-frame bitstream in git master)

imho just drop the scm tool name

>  - add support for using mplayers video filters to ffmpeg
>  - H264 encoder
>  - per MB ratecontrol (so VCD and such do work better)
> diff --git a/doc/developer.texi b/doc/developer.texi
> index b9e246f..e0b64d7 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -312,7 +312,7 @@ send a reminder by email. Your patch should eventually be dealt with.
>      If it depends on a parser or a library, did you add that dependency in
>      configure?
>  @item
> -    Did you "svn add" the appropriate files before commiting?
> +    Did you "git add" the appropriate files before commiting?
>  @end enumerate
>  
>  @section patch submission checklist
> @@ -325,7 +325,7 @@ send a reminder by email. Your patch should eventually be dealt with.
>  @item
>      Is the patch a unified diff?
>  @item
> -    Is the patch against latest FFmpeg SVN?
> +    Is the patch against latest FFmpeg git master branch?
>  @item
>      Are you subscribed to ffmpeg-dev?
>      (the list is subscribers only due to spam)
> @@ -388,7 +388,7 @@ send a reminder by email. Your patch should eventually be dealt with.
>  @section Patch review process
>  
>  All patches posted to ffmpeg-devel will be reviewed, unless they contain a
> -clear note that the patch is not for SVN.
> +clear note that the patch is not for the git master branch.
>  Reviews and comments will be posted as replies to the patch on the
>  mailing list. The patch submitter then has to take care of every comment,
>  that can be by resubmitting a changed patch or by discussion. Resubmitted

ok, but we need to update this

> diff --git a/doc/optimization.txt b/doc/optimization.txt
> index 5d51235..5759d0d 100644
> --- a/doc/optimization.txt
> +++ b/doc/optimization.txt
> @@ -17,8 +17,8 @@ Understanding these overoptimized functions:
>  As many functions tend to be a bit difficult to understand because
>  of optimizations, it can be hard to optimize them further, or write
>  architecture-specific versions. It is recommended to look at older
> -revisions of the interesting files (for a web frontend try ViewVC at
> -http://svn.ffmpeg.org/ffmpeg/trunk/).
> +revisions of the interesting files (for a web frontend try gitweb at
> +http://git.ffmpeg.org/?p=ffmpeg.git;a=summary).
>  Alternatively, look into the other architecture-specific versions in
>  the x86/, ppc/, alpha/ subdirectories. Even if you don't exactly
>  comprehend the instructions, it could help understanding the functions
> diff --git a/doc/soc.txt b/doc/soc.txt
> index 8b4a86d..79d77d1 100644
> --- a/doc/soc.txt
> +++ b/doc/soc.txt
> @@ -9,14 +9,14 @@ it's a little late for this year's soc (2006).
>  The Goal:
>  Our goal in respect to soc is and must be of course exactly one thing and
>  that is to improve FFmpeg, to reach this goal, code must
> -* conform to the svn policy and patch submission guidelines
> +* conform to the development policy and patch submission guidelines
>  * must improve FFmpeg somehow (faster, smaller, "better",
>    more codecs supported, fewer bugs, cleaner, ...)
>  
>  for mentors and other developers to help students to reach that goal it is
>  essential that changes to their codebase are publicly visible, clean and
>  easy reviewable that again leads us to:
> -* use of a revision control system like svn
> +* use of a revision control system like git
>  * separation of cosmetic from non-cosmetic changes (this is almost entirely
>    ignored by mentors and students in soc 2006 which might lead to a suprise
>    when the code will be reviewed at the end before a possible inclusion in

ok

Janne



More information about the ffmpeg-devel mailing list