[svnbook commit] r1241 - in trunk/src/nb: . book
sunny256
svnbook-dev at red-bean.com
Tue Apr 26 02:06:03 CDT 2005
Author: sunny256
Date: Tue Apr 26 02:06:02 2005
New Revision: 1241
Modified:
trunk/src/nb/LAST_UPDATED
trunk/src/nb/README
trunk/src/nb/REVIEW
trunk/src/nb/TODO
trunk/src/nb/book/ch04.xml
trunk/src/nb/book/ch06.xml
Log:
Synchronise the English and Norwegian svnbook with "make sync". Updated
changes between r1223:1240.
* src/nb/LAST_UPDATED
Updated to 1240 by "make sync".
* src/nb/README
Merged r1228.
* src/nb/REVIEW
Merged r1229.
* src/nb/TODO
Merged r1231, r1232, r1233, r1234.
* src/nb/book/ch04.xml
Merged and updated r1231, r1232, r1235, r1238. New "The Key Concept
Behind Merging" section.
* src/nb/book/ch06.xml
Merged r1232.
Modified: trunk/src/nb/LAST_UPDATED
==============================================================================
--- trunk/src/nb/LAST_UPDATED (original)
+++ trunk/src/nb/LAST_UPDATED Tue Apr 26 02:06:02 2005
@@ -1 +1 @@
-1223
+1240
Modified: trunk/src/nb/README
==============================================================================
--- trunk/src/nb/README (original)
+++ trunk/src/nb/README Tue Apr 26 02:06:02 2005
@@ -24,20 +24,11 @@
It's very short and clears up many things.
- Note that there are actually two DocBook documents here: The book
- itself, "Version Control with Subversion", and a miscellaneous
- holding area known only as the "misc docs" (e.g., misc-docs.pdf,
- etc). The Misc Docs hold material that either isn't yet ready to go
- into the book itself, or which may never go into the book but
- instead into companion documents that will also be available from
- the Subversion site. Think of Misc Docs as a temporary, but
- published, holding area.
-
II. COMPILING THE DOCS
-1. Fetch XSL stylesheets for Docbook and place them in src/tools/xsl
+1. Fetch XSL stylesheets for Docbook and place them in src/tools/xsl.
The "Docbook Open Repository" on Sourceforge has a large collection
of XSL stylesheets that specifically operate on Docbook. Download
@@ -78,12 +69,12 @@
If you don't want to compile libxslt, you can just fetch the
appropriate OS binary package.
- * From the book directory, do
+ * From this directory (en, or another language directory), do
- make all-html
+ $ make all-html
This produces a single-page HTML version of the book in
- book/book.html, and a multi-page version in book/html-chunk/.
+ book/svn-book.html, and a multi-page version in book/html-chunk/.
3. Make a PDF file.
@@ -100,16 +91,16 @@
installed FOP some other way, that's fine, then you can ignore
the following recipe:
- 1. Download the latest from
+ 1. Download the latest version from
http://www.apache.org/dyn/closer.cgi/xml/fop, for example,
- fop-0.20.4-bin.tar.gz. Just get a binary distribution,
+ fop-0.20.5-bin.tar.gz. Just get a binary distribution,
there's no need for the Java source.
2. Unpack it into src/tools/fop/
$ cd src/tools
$ tar zxvf fop-0.20.4-bin.tar.gz
- $ mv fop-0.20.4 fop
+ $ mv fop-0.20.5 fop
That should be enough. The Makefile will actually invoke
src/tools/bin/run-fop.sh. That script attempts to find FOP already
@@ -142,11 +133,11 @@
Poof! You now have PNG support.
- * From the book directory, do
+ * From this directory (en, or another language directory), do
- make all-pdf
+ $ make all-pdf
- This produces PDF for the book in book/book.pdf.
+ This produces PDF for the book in book/svn-book.pdf.
III. HACKING ON THE DOCS
@@ -172,16 +163,14 @@
2. Get a validating parser.
- We recommend nsgmls, a parser written by James Clark:
- http://www.jclark.com/sp/. It's nice to check that the XML
- you write has matching tags, and follows the DTD correctly.
-
- Here is one command you can use to validate your xml:
-
- $ SP_CHARSET_FIXED=YES SP_ENCODING=XML nsgmls -wxml \
- -mdeclaration/xml.soc -ges \
- /path/to/your/declaration/xml.dcl book.xml
-
+ Actually, if you have what you need to compile the documentation,
+ then you almost certainly have an XML validator installed already -
+ it is called xmllint, and comes as part of libxml2.
+
+ The makefile is preconfigured with a suitable invocation of it,
+ so simply run:
+
+ $ make valid
3. Read about the DocBook lite tags.
Modified: trunk/src/nb/REVIEW
==============================================================================
--- trunk/src/nb/REVIEW (original)
+++ trunk/src/nb/REVIEW Tue Apr 26 02:06:02 2005
@@ -9,6 +9,17 @@
http://www.svnbook.org/examples/
+ #2) Gareth McCaughan (from issue #1216)
+
+ There are lots of instances of "..." that should probably be
+ replaced with "…".
+
+ Capitalization of section headings is quite inconsistent.
+ Most have all significant words capitalized ("Examine Your
+ Changes"), but some don't ("How to Read this Book"). It
+ doesn't much matter which convention is chosen, but it's
+ probably best to stick with one.
+
Chapter 3
#1) ghudson (also affects ch 9 a little bit)
@@ -31,6 +42,23 @@
designation, and of course the time zone designation may
be "-hh[:mm]" instead of "+hh[:mm]".
+ Examining History : svn log
+
+ #2) Gareth McCaughan (from issue #1216)
+
+ It would be good to say something here about the interaction
+ between "svn log" and the ability to move files and
+ directories around. Maybe just a pointer to where it's
+ discussed more fully.
+
+ Examining History : A Final Word on History
+
+ #3) Gareth McCaughan (from issue #1216)
+
+ Anyone who's used CVS will be wondering: if I use "svn
+ update" with the --revision flag to move back in time, what
+ then happens when I do later updates without that flag?
+
Chapter 5
Section svn-ch-5-sect-6
@@ -52,6 +80,143 @@
could well be merged into. If that doesn't work, I would
consider moving it up to the front of this chapter.
+ Repository Basics : Unversioned Properties
+
+ #2) Gareth McCaughan (from issue #1216)
+
+ It may be worth explicitly saying that these are *not* the
+ same as the versioned properties attached to files and
+ directories.
+
+ Repository Creation and Configuration
+
+ #3) Gareth McCaughan (from issue #1216)
+
+ "A file whose contents are a single integer value ...": that
+ could mean either a string of characters representing an
+ integer in base 10, or a bunch of bytes representing an
+ integer in base 256. Presumably it means the former; maybe
+ add "in base 10" to the text?
+
+ Repository Creation and Configuration : Hook scripts
+
+ #4) Gareth McCaughan (from issue #1216)
+
+ At the end of this section, there's a note about permissions
+ and file ownership and so on. It slightly gives the
+ impression that the main failure mode in this area is having
+ a hook script that can't do what you want because it doesn't
+ have permission. Well, maybe that's the commonest failure
+ mode, but there's a more serious failure mode where the
+ script can do altogether too much because it has too much
+ permission. Is it worth adding some mumblings about
+ security?
+
+ Repository Maintenance : An Administrator's Toolkit : Berkeley DB Utilities
+
+ #5) Gareth McCaughan (from issue #1216)
+
+ The text says that db_dump and db_load are useful for
+ transferring Berkeley databases from one machine to another.
+ It would be good to clarify the relationship between these
+ and "svnadmin dump" and "svnadmin load". (That is, that
+ there isn't any, and that Subversion users want to use the
+ latter rather than the former.)
+
+ Repository Maintenance : Repository Cleanup
+
+ #6) Gareth McCaughan (from issue #1216)
+
+ "If you use these two subcommands like this, you should
+ consider making your repository temporarily inaccessible to
+ clients." -- this advice would be much more helpful if it
+ said how to do it. Later in the book, there's a similar
+ piece of advice that recommends killing the svnserve or
+ Apache process, but (1) Apache might be being used for other
+ things that you don't want to kill, (2) if you're using
+ svnserve over ssh, doesn't each user have their own
+ process?, and (3) this doesn't help if you have users
+ accessing the repository directly. Hmm.
+
+ Repository Maintenance : Migrating a Repository
+
+ #7) Gareth McCaughan (from issue #1216)
+
+ "The only exception to this rule is the first revision that
+ is dumped with the current svnadmin dump command." I'm not
+ sure what "current" is meant to mean here. How about "...
+ that is dumped with each svnadmin dump command."?
+
+ "And, secondly, Subversion cannot know the state of the
+ repository into which the dump data will be loaded (if it
+ ever, in fact, occurs)." Er, if *what* ever occurs? Loading
+ of the dump into a repository? If that's the meaning, then I
+ suggest: "... into which the dump data will be loaded, if
+ indeed it's ever loaded into a repository at all."
+
+ The section about incremental repository dumps would, I
+ think, be improved if it said *explicitly* that the
+ concatenation of two dumps is a legal dump.
+
+
+Chapter 7
+
+ Properties : Special properties : svn:ignore
+
+ #1) Gareth McCaughan (from issue #1216)
+
+ It might be worth making a bigger deal of the one really key
+ difference between svn:ignore and .cvsignore: the former
+ will always get checked in whenever the directory it applies
+ to does, whereas you can leave .cvsignore un-checked-in.
+ This is alluded to in passing ("These facts are true for all
+ working copies, not just your own."), but it should probably
+ be mentioned in the box "Ignore Patterns for CVS Users".
+
+ Properties : Special properties : svn:keywords
+
+ #2) Gareth McCaughan (from issue #1216)
+
+ The exact treatment of the briefer aliases for keywords
+ isn't very clear. Specifically, I can't tell from the
+ description here (1) whether, if I include "LastChangedDate"
+ in svn:keywords, "$Date$" will get expanded or not, nor (2)
+ whether, if I have "$Date$" and it gets expanded, it turns
+ into "$Date: ...$" or "$LastChangedDate: ...$".
+
+ Properties : Special properties : svn:eol-style
+
+ #3) Gareth McCaughan (from issue #1216)
+
+ "This is basically transparent to the user, though.": every
+ time I see "basically" in a technical book it makes me
+ shudder, because I'm afraid that underneath it lurk some
+ nasty details that the author is afraid to touch. This
+ should either say "This is transparent to the user." or else
+ explain briefly the ways in which it's not quite
+ transparent.
+
+ Externals Definitions
+
+ #4) Gareth McCaughan (from issue #1216)
+
+ "no one else has to Subver-bother---sion": wow! This appears
+ to be a bug in whatever generated the PDF form of the
+ document, because the source looks fine :-).
+
+
+Chapter 8
+
+ Using the APIs : Using Languages Other than C and C++
+
+ #1) Gareth McCaughan (from issue #1216)
+
+ "Our example will do the same thing as our last example": no
+ it won't. The previous example was a function to create a
+ directory in the repository; this one enumerates paths below
+ a given point in the repository. What it's the same as is
+ the example in the section on memory pools, but that's later
+ in the book.
Chapter 9
@@ -66,3 +231,30 @@
#2) naked
"svn merge" has the same problem as above.
+
+Appendix A
+
+ Directory Versions
+
+ #1) Gareth McCaughan (from issue #1216)
+
+ "For more discussion about the limitations of directory
+ versioning, see ...": it looks to me as if the referenced
+ section contains strictly *less* about the limitations of
+ directory versioning than the preceding paragraphs in
+ appendix A. Someone turning there will learn nothing new.
+
+Appendix C
+
+ Common Problems : Problems Using Subversion
+
+ #1) Gareth McCaughan (from issue #1216)
+
+ The first problem meets with the suggestion of running "svn
+ recover", and says "Make sure you run this command as the
+ user that owns and manages the database ...". Perhaps it
+ should say something about what to do if you run it as root
+ by mistake. (Is "chown -R user:group /path/to/repos"
+ sufficient, for instance?)
+
+
Modified: trunk/src/nb/TODO
==============================================================================
--- trunk/src/nb/TODO (original)
+++ trunk/src/nb/TODO Tue Apr 26 02:06:02 2005
@@ -38,6 +38,16 @@
To be fixed by fitz:
+ch03:
+
+ - explain the "magic rule" of working copy management: you must
+ always use 'svn' to manipulate files and dirs (cp, mv, add, rm,
+ etc.), *except* for editing. Editing can be done without telling
+ svn; it notices this later on. users are craving these two
+ simple sentences as an overview at the beginning of the chapter;
+ for someone who has never used CVS, it's apparently quite
+ confusing as to what sort of manipulations do and don't require
+ 'svn'.
@@ -50,48 +60,24 @@
not overwritten by a tarball explode wouldn't be missing, they'd
be untouched).
- - document the --ignore-externals option (added 'update',
- 'checkout', 'export', and 'status'). Don't forget the reference
- section.
-
- - document the --use-[pre|post]-commit-hook option to 'svnadmin
- load'. Don't forget the reference section.
--------------------------------------------------------------
To be fixed by sussman:
-ch03:
-
- - "magic rule" of working copy management: you must *always* use
- 'svn' to manipulate files and dirs (cp, mv, add, rm, etc.),
- *except* for editing. Editing can be done without telling svn;
- it notices this later on.
-
ch04:
- - "magic rule" of the merge command: "diff and apply". explain the
- 2 URLs + 1 WC arguments. compare URLs, apply diff to wc.
-
- - need a giant warning-box about how our lack of 'true renames' can
- be really irritating when doing merges. The classic case is when
- branchA moves things around, and branch B just changes file text.
- When you merge branchA into branchB, you deleting the newer file
- versions and adding-with-history the older file versions.
- Definitely a big 'gotcha' to watch out for.
-
- - "common use-cases for merging" shows -r405:HEAD. let's not
- encourage HEAD, since that can be a dangerous practice. should
- explain *why* we're not using head.
+ - need a giant warning-box about issue #2282. how our lack of
+ 'true renames' can be really irritating when doing merges. The
+ classic case is when branchA moves things around, and branch B
+ just changes file text. When you merge branchA into branchB, you
+ deleting the newer file versions and adding-with-history the
+ older file versions. Definitely a big 'gotcha' to watch out for.
ch06:
- - svnserve->set access controls->last paragraph:
- Don't just mention svnserve for path-based access;
- mention the pre-commit hooks for at controlling path-based write.
-
- explain shortcoming in http checkout authorization. because
checkout is done as one http request, there's only one chance to
authenticate (or not). if root-dir is anonymously readable, then
@@ -114,31 +100,76 @@
* Need whole new section to explain "peg objects" and history
tracing. Lots of examples involving different subcommands.
- (Which chapter should this section go in?)
+
+ This is probably too much information to go into the chapter 3
+ svn client tutorial. It should probably be a new "advanced
+ topics" section in chapter 7 (MIKE).
+
+ * Need whole new section explaining activating l10n (LOCALE=) for
+ message translations, and how and IRI autoescaping works.
- * Need whole new section explaining activating l10n and IRI autoescaping.
- (What chapter should this section go in?)
+ This probably needs to be an "advanced topics" chapter 7
+ section (MIKE).
* New 'SVNPathAuthz Off' directive, to disable path-based authz in
- apache (and increase speed.) Really, chapter 9 needs a
- 'definitive list' of all mod_dav_svn directives.
+ apache (and increase speed.)
+
+ (BEN) will mention this in chapter 6, but:
+
+ * Need 'definitive list' of all mod_dav_svn directives.
+
+ (FITZ) new chapter 9 section.
- With svn 1.1, it's now possible to set up svn+ssh using just one
Unix account on the server. The book should perhaps document this
way of setting up svn+ssh. See notes/ssh-tricks for details.
+ (BEN) will add this to chapter 6 section on svn+ssh://.
+
+ - check that all the new 1.1 command switches are documented in ch09.
+ See http://subversion.tigris.org/svn_1.1_releasenotes.html for list.
+
+ (FITZ) this is chapter 9 touchup work.
+
List of 1.2 features/changes (that still need to be documented)
============================
- * svn log --limit
- * Fixed length keywords
+ * ch00: "what's new in svn 1.2". Ben will do this, like he did for
+ the 1.1 book.
+
+ * the new locking feature, and all of its many tendrils.
+ touches chapters 2, 3, 5, 9 at a minimum. (we should all work on this)
+
+ * ch05: comparison of bdb and fsfs: make it clear that fsfs is now
+ the default, need --fs-type bdb to get bdb. (mike)
+
+ * ch06: client-cred-caching: mention win32 encryption in
+ mod_authz_svn: groups can contain other groups (BEN)
+
+ * Fixed length keywords (MIKE chapter 7)
The format of fixed length keyword and its data is
- Unexpanded keyword: "$keyword:: $"
- Expanded keyword: "$keyword:: value $"
- Expanded kw with filling: "$keyword:: value $"
- Truncated keyword: "$keyword:: longval#$"
- * New revprop hook features (ch05)
+
+ * New revprop hook features (ch05 MIKE)
- Added fifth ACTION argument (A, M, or D)
- New/old revprop value available on stdin
+
+ * Chapter 5 (MIKE): document the --use-[pre|post]-commit-hook option
+ to 'svnadmin load'.
+
+ * Chapter 7 (MIKE): document the --ignore-externals option (added
+ 'update', 'checkout', 'export', and 'status'). Don't forget the
+ reference section.
+
+ * bunches of new command switches, see the CHANGES entry for 1.2.
+ (FITZ), chapter 9.
+
+ * rewrite huge chunks of autoversioning appendix C (BEN)
+
+
+
Modified: trunk/src/nb/book/ch04.xml
==============================================================================
--- trunk/src/nb/book/ch04.xml (original)
+++ trunk/src/nb/book/ch04.xml Tue Apr 26 02:06:02 2005
@@ -1260,11 +1260,178 @@
<sect2 id="svn-ch-4-sect-3.2">
<!-- @ENGLISH {{{
+ <title>The Key Concept Behind Merging</title>
+ @ENGLISH }}} -->
+ <title>Nøkkelkonseptet bak fletting</title>
+
+ <!-- @ENGLISH {{{
+ <para>You've now seen an example of the <command>svn
+ merge</command> command, and you're about to see several
+ more. If you're feeling confused about exactly how merging
+ works, you're not alone. Many users (especially those new
+ to version control) are initially perplexed about the proper
+ syntax of the command, and about how and when the feature
+ should be used. But fear not, this command is actually much
+ simpler than you think! There's a very easy technique for
+ understanding exactly how <command>svn merge</command>
+ behaves.</para>
+ @ENGLISH }}} -->
+ <para>Du har nå sett et eksempel på <command>svn
+ merge</command>-kommandoen, og du skal få se fler.
+ Hvis du er forvirret omkring hvordan fletting faktisk virker, er
+ du ikke alene om det.
+ Mange brukere (spesielt de som er ny innen versjonskontroll) er
+ usikker på den riktige syntaksen til kommandoen, og når denne
+ funksjonaliteten skal brukes.
+ Men frykt ikke, denne kommandoen er faktisk mye enklere enn du
+ tror!
+ Det er en veldig enkel teknikk for å forstå nøyaktig hvordan
+ <command>svn merge</command> virker.</para>
+
+ <!-- @ENGLISH {{{
+ <para>The main source of confusion is the
+ <emphasis>name</emphasis> of the command. The term
+ <quote>merge</quote> somehow denotes that branches are
+ combined together, or that there's some sort of mysterious
+ blending of data going on. That's not the case. A better
+ name for the command might have been <command>svn
+ diff-and-apply</command>, because that's all that happens:
+ two repository trees are compared, and the differences are
+ applied to a working copy.</para>
+ @ENGLISH }}} -->
+ <para>Hovedkilden til forvirringen er <emphasis>navnet</emphasis>
+ på kommandoen.
+ Terminologien <foreignphrase>merge</foreignphrase> –
+ <quote>flette</quote> – indikerer på en måte at grener blir
+ kombinert sammen, eller at det er en form for mystisk
+ sammenblanding av data som foregår.
+ Det er ikke tilfellet.
+ Et bedre navn for kommandoen hadde vært <command>svn
+ diff-and-apply</command> – <quote>finn forskjell og legg denne
+ til</quote> – fordi det er alt som skjer:
+ To depottrær blir sammenlignet, og forskjellene blir lagt inn i
+ arbeidskopien.</para>
+
+ <!-- @ENGLISH {{{
+ <para>The command takes three arguments:</para>
+ @ENGLISH }}} -->
+ <para>Kommandoen tar tre argumenter:</para>
+
+ <orderedlist>
+
+ <!-- @ENGLISH {{{
+ <listitem><para>An initial repository tree (often called the
+ <firstterm>left side</firstterm> of the
+ comparison),</para></listitem>
+ @ENGLISH }}} -->
+ <listitem>
+ <para>Et innledende depottre (ofte kalt den <firstterm>venstre
+ siden</firstterm> av sammenligningen,</para>
+ </listitem>
+
+ <!-- @ENGLISH {{{
+ <listitem><para>An final repository tree (often called the
+ <firstterm>right side</firstterm> of the
+ comparison),</para></listitem>
+ @ENGLISH }}} -->
+ <listitem>
+ <para>Et slutt-depottre (ofte kalt den <firstterm>høyre
+ siden</firstterm> av sammenligningen,</para>
+ </listitem>
+
+ <!-- @ENGLISH {{{
+ <listitem><para>A working copy to accept the differences as
+ local changes (often called the <firstterm>target</firstterm>
+ of the merge.)</para></listitem>
+ @ENGLISH }}} -->
+ <listitem>
+ <para>En arbeidskopi som skal motta forandringene som lokale
+ forandringer (ofte kalt <firstterm>målet</firstterm> til
+ flettingen).</para>
+ </listitem>
+
+ </orderedlist>
+
+ <!-- @ENGLISH {{{
+ <para>Once these three arguments are specified, the two trees
+ are compared, and the resulting differences are applied to the
+ target working copy as local modifications. When the command
+ is done, the results are no different than if you had
+ hand-edited the files, or run various <command>svn
+ add</command> or <command>svn delete</command> commands
+ yourself. If you like the results, you can commit them. If
+ you don't like the results, you can simply <command>svn
+ revert</command> all of the changes.</para>
+ @ENGLISH }}} -->
+ <para>Når disse tre argumentene er spesifisert, blir de to trærne
+ sammenlignet og de forskjellene som programmet finner blir lagt
+ inn i mål-arbeidskopien som lokale forandringer.
+ Når kommandoen er ferdig, er ikke resultatet forskjellig fra om
+ du hadde redigert filene for hånd, eller selv kjørt diverse
+ <command>svn add</command> eller <command>svn
+ delete</command>-kommandoer.
+ Hvis du ikke liker resultatene, kan du enkelt <command>svn
+ revert</command> alle forandringene.</para>
+
+ <!-- @ENGLISH {{{
+ <para>The syntax of <command>svn merge</command> allows you to
+ specify the three necessary arguments rather flexibly. Here
+ are some examples:</para>
+ @ENGLISH }}} -->
+ <para>Syntaksen til <command>svn merge</command> lar deg
+ spesifisere de tre nødvendige argumentene ganske fleksibelt.
+ her er noen eksempler:</para>
+
+<!-- @ENGLISH {{{
+<screen>
+$ svn merge http://svn.example.com/repos/branch1@150 \
+ http://svn.example.com/repos/branch2@212 \
+ my-working-copy
+
+$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy
+
+$ svn merge -r 100:200 http://svn.example.com/repos/trunk
+</screen>
+ at ENGLISH }}} -->
+ <screen>
+$ svn merge http://svn.example.com/repos/branch1@150 \
+ http://svn.example.com/repos/branch2@212 \
+ min-arbeidskopi
+
+$ svn merge -r 100:200 http://svn.example.com/repos/trunk min-arbeidskopi
+
+$ svn merge -r 100:200 http://svn.example.com/repos/trunk
+</screen>
+
+ <!-- @ENGLISH {{{
+ <para>The first syntax lays out all three arguments explictly,
+ naming each tree in the form <emphasis>URL at REV</emphasis> and
+ naming the working copy target. The second syntax can be used
+ as a shorthand for situations when you're comparing two
+ different revisions of the same URL. The last syntax shows
+ how the working-copy argument is optional; if omitted, it
+ defaults to the current directory.</para>
+ @ENGLISH }}} -->
+ <para>Den første syntaksen legger spesifikt opp alle tre
+ argumentene, ved å nevne hvert tre på formen
+ <emphasis>URL at REV</emphasis> og nevne arbeidskopimålet.
+ Den andre syntaksen kan bli brukt som en snarvei for situasjoner
+ når du sammenligner to forskjellige revisjoner til den samme
+ URLen.
+ Den siste syntaksen viser hvordan arbeidskopiargumentet er
+ valgfritt; hvis det er utelatt, brukes den gjeldende
+ katalogen.</para>
+
+
+ </sect2>
+
+ <sect2 id="svn-ch-4-sect-3.3">
+ <!-- @ENGLISH {{{
<title>Best Practices for Merging</title>
@ENGLISH }}} -->
<title>Beste praksis for fletting</title>
- <sect3 id="svn-ch-4-sect-3.2.1">
+ <sect3 id="svn-ch-4-sect-3.3.1">
<!-- @ENGLISH {{{
<title>Tracking Merges Manually</title>
@ENGLISH }}} -->
@@ -1361,7 +1528,7 @@
</sect3>
- <sect3 id="svn-ch-4-sect-3.2.2">
+ <sect3 id="svn-ch-4-sect-3.3.2">
<!-- @ENGLISH {{{
<title>Previewing Merges</title>
@ENGLISH }}} -->
@@ -1523,7 +1690,7 @@
forandringssett #9238 inn i arbeidskopien din.</para>
</sidebar>
- <sect3 id="svn-ch-4-sect-3.2.3">
+ <sect3 id="svn-ch-4-sect-3.3.3">
<!-- @ENGLISH {{{
<title>Merge Conflicts</title>
@ENGLISH }}} -->
@@ -1706,7 +1873,7 @@
</sect3>
- <sect3 id="svn-ch-4-sect-3.2.4">
+ <sect3 id="svn-ch-4-sect-3.3.4">
<!-- @ENGLISH {{{
<title>Noticing or Ignoring Ancestry</title>
@ENGLISH }}} -->
@@ -2028,7 +2195,7 @@
$ svn update
At revision 405.
-$ svn merge -r 341:HEAD http://svn.example.com/repos/calc/branches/my-calc-branch
+$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
U integer.c
U button.c
U Makefile
@@ -2053,7 +2220,7 @@
$ svn update
At revision 405.
-$ svn merge -r 341:HEAD http://svn.example.com/repos/calc/branches/my-calc-branch
+$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
U integer.c
U button.c
U Makefile
@@ -2090,7 +2257,7 @@
to your original feature or bug fix. The repository's
<literal>HEAD</literal> revision is now 480, and you're ready
to do another merge from your private branch to the trunk.
- But as discussed in <xref linkend="svn-ch-4-sect-3.2"/>, you
+ But as discussed in <xref linkend="svn-ch-4-sect-3.3"/>, you
don't want to merge the changes you've already merged before;
you only want to merge everything <quote>new</quote> on your
branch since the last time you merged. The trick is to figure
@@ -2102,7 +2269,7 @@
Depotets <literal>HEAD</literal>-revisjon er nå 480, og du er
klar til å utføre en ny fletting fra den private grenen din til
trunk.
- Men som diskutert i <xref linkend="svn-ch-4-sect-3.2"/> vil du
+ Men som diskutert i <xref linkend="svn-ch-4-sect-3.3"/> vil du
ikke flette forandringene du allerede har flettet før; du vil
bare flette alt <quote>nytt</quote> på grenen siden forrige gang
du flettet.
@@ -2955,7 +3122,7 @@
merge the last week's worth of trunk changes to the branch.
Take care when doing this; the merging needs to be
hand-tracked to avoid the problem of repeated merges (as
- described in <xref linkend="svn-ch-4-sect-3.2.1"/>). You'll
+ described in <xref linkend="svn-ch-4-sect-3.3.1"/>). You'll
need to write careful log messages detailing exactly which
revision ranges have been been merged already (as
demonstrated in <xref linkend="svn-ch-4-sect-4.1"/>). It
@@ -2969,7 +3136,7 @@
grenen.
Vær nøye når du gjør dette; flettingen må <!-- ¤ -->sjekkes
for å unngå problemet med gjentatte flettinger (som beskrevet
- i <xref linkend="svn-ch-4-sect-3.2.1"/>).
+ i <xref linkend="svn-ch-4-sect-3.3.1"/>).
Du må skrive nøyaktige loggmeldinger med detaljer om hvilket
revisjonsområde som allerede er blitt flettet (som demonstrert
i <xref linkend="svn-ch-4-sect-4.1"/>).
@@ -2998,14 +3165,14 @@
<!-- ¤ -->
<!-- @ENGLISH {{{
-<screen>
+ <screen>
$ cd trunk-working-copy
$ svn update
At revision 1910.
$ svn merge http://svn.example.com/repos/calc/trunk@1910 \
- http://svn.example.com/repos/calc/branches/mybranch@1910 \
+ http://svn.example.com/repos/calc/branches/mybranch@1910
U real.c
U integer.c
A newdirectory
@@ -3013,14 +3180,14 @@
…
</screen>
@ENGLISH }}} -->
-<screen>
+ <screen>
$ cd trunk-working-copy
$ svn update
At revision 1910.
$ svn merge http://svn.example.com/repos/calc/trunk@1910 \
- http://svn.example.com/repos/calc/branches/mybranch@1910 \
+ http://svn.example.com/repos/calc/branches/mybranch@1910
U real.c
U integer.c
A newdirectory
Modified: trunk/src/nb/book/ch06.xml
==============================================================================
--- trunk/src/nb/book/ch06.xml (original)
+++ trunk/src/nb/book/ch06.xml Tue Apr 26 02:06:02 2005
@@ -476,10 +476,11 @@
<title>Servers and Permissions: A Word of Warning</title>
<para>First, remember that a Subversion repository is a
- collection of BerkeleyDB database files; any process which
- accesses the repository directly needs to have proper read
- and write permissions on the entire repository. If you're
- not careful, this can lead to a number of headaches. Be
+ collection of database files; any process which accesses the
+ repository directly needs to have proper read and write
+ permissions on the entire repository. If you're not
+ careful, this can lead to a number of headaches, especially
+ if you're using a BerkeleyDB database rather than FSFS. Be
sure to read <xref linkend="svn-ch-6-sect-5"/>.</para>
<para>Secondly, when configuring <command>svnserve</command>,
@@ -689,24 +690,17 @@
specific paths within the repository. For many projects and
sites, this level of access control is more than adequate.
However, if you need per-directory access control, you'll
- need to use Apache instead of <command>svnserve</command> as
- your server process.</para>
+ need to use either use Apache with
+ <command>mod_authz_svn</command> (see <xref
+ linkend="svn-ch-6-sect-4.4.2"/>) or use a
+ <command>pre-commit</command> hook script to control write
+ access (see <xref linkend="svn-ch-5-sect-2.1"/>). The
+ Subversion distribution comes with
+ <command>commit-access-control.pl</command> and the more
+ sophisticated <command>svnperms.py</command> scripts for use
+ in pre-commit scripts.</para>
</sect3>
-
- </sect2>
-
-
- <sect2 id="svn-ch-6-sect-3.3">
- <title>External path-based authorization</title>
-
- <para>While <command>svnserve</command> itself does not provide
- any means to control per-path authorization, a pre-commit hook
- can be used to enforce per-path write access control. The
- Subversion distribution comes with
- <command>commit-access-control.pl</command> and the more
- sophisticated <command>svnperms.py</command> scripts for use
- in pre-commit scripts.</para>
</sect2>
<sect2 id="svn-ch-6-sect-3.4">
More information about the svnbook-dev
mailing list