summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorReinhard Tartler <siretart@tauware.de>2011-02-07 17:17:30 +0100
committerReinhard Tartler <siretart@tauware.de>2011-02-08 22:07:02 +0100
commit87800dc2bf8f2724a99e51bb079ad7fb4b9dfd3b (patch)
treea544f7bc9e9dd5478858b01388cee3cc7c2d3cd8
parentae2104791ffa8466d3f6972ed0793b2a165daabe (diff)
Documentation updates for the git migration
This cleanup patch updates the developer documentation with respect to the migration to the git scm.
-rw-r--r--doc/TODO2
-rw-r--r--doc/developer.texi6
-rw-r--r--doc/optimization.txt4
-rw-r--r--doc/soc.txt4
4 files changed, 8 insertions, 8 deletions
diff --git a/doc/TODO b/doc/TODO
index 747eee4ab1..8ff8a6b388 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 the 'master' branch)
- 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 b9e246f214..acffbe67e2 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 committing?
@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
diff --git a/doc/optimization.txt b/doc/optimization.txt
index 5d51235983..08954f9973 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 (web frontends for the various FFmpeg
+branches are listed at http://ffmpeg.org/download.html).
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 8b4a86db80..79d77d1cd7 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