[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