Propchange: subversion/site/staging/blog/2008-05-06-merge-info.html
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: subversion/site/staging/blog/2008-05-06-merge-info.html
------------------------------------------------------------------------------
svn:mime-type = text/html
Added:
subversion/site/staging/blog/2009-11-19-where-did-that-mergeinfo-come-from.html
URL:
http://svn.apache.org/viewvc/subversion/site/staging/blog/2009-11-19-where-did-that-mergeinfo-come-from.html?rev=1908741&view=auto
==============================================================================
---
subversion/site/staging/blog/2009-11-19-where-did-that-mergeinfo-come-from.html
(added)
+++
subversion/site/staging/blog/2009-11-19-where-did-that-mergeinfo-come-from.html
Sun Mar 26 20:17:15 2023
@@ -0,0 +1,153 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta charset="UTF-8">
+<meta http-equiv="x-ua-compatible" content="ie=edge">
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+<title>Apache Subversion Mergeinfo - Understanding the internals</title>
+<meta name="description" content="Subversion 1.8 server dictated configuration
part 1 of 3: Introduction to inheritable properties">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<link rel="manifest" href="/site.webmanifest">
+<link rel="apple-touch-icon" href="/icon.png">
+<link rel="icon" type="image/png" href="/icon.png">
+<link rel="stylesheet" href="/style/site.css" type="text/css" media="all">
+<meta name="theme-color" content="#98b0d4">
+</head>
+
+<body>
+<!--#include virtual="/site-banner.html" -->
+<!--#include virtual="/site-nav.html" -->
+<div id="site-content">
+<!--#include virtual="/site-notice.html" -->
+<!-- **************** BEGIN CONTENT ***************** -->
+
+<h1>Where Did That Mergeinfo Come From?</h1>
+<div>
+<p>This article is mirrored with permission from the original location
http://blogs.collab.net/subversion/where-did-that-mergeinfo-come-from. Inactive
links has been removed or updated.</p>
+
+<p><strong>Author:</strong> Paul Burba</p>
+<p><strong>Posted:</strong> 2009-11-19</p>
+
+<p>One area of merge tracking that has caused confusion is how svn:mergeinfo
properties are set.  In many common use cases only mergeinfo on the
merge target is set.  There are however, many scenarios where mergeinfo
under the target, so called "subtree mergeinfo", is created or
updated.  These situations often leave users wondering if something
went wrong during the merge and if they should commit these subtree mergeinfo
changes.  That confusion is compounded by the fact that a given subtree
may have no changes other than those made to the svn:mergeinfo property
itself.</p>
+<p>This post describes some common cases where subtree mergeinfo is created or
updated during a merge.</p>
+</div>
+
+<div class="h2" id="pre-existing-subtree-mergeinfo">
+<h2>Pre-existing Subtree Mergeinfo
+<a class="sectionlink" href="#pre-existing-subtree-mergeinfo"
+ title="Link to this section">¶</a>
+</h2>
+<p>By far the most common cause of subtree mergeinfo changes is when your
working copy merge target has subtree mergeinfo <em>prior </em>to a merge.</p>
+<p>For example, we have a branch B1.0, created from trunk, that has some
subtree mergeinfo:</p>
+<p><code>1.6.6>svn propget svn:mergeinfo branches/B1.0 -vR<br/>Properties
on 'branches/B1.0/A/D/H/psi':<br/> 
svn:mergeinfo<br/>    /trunk/A/D/H/psi:4-10</code></p>
+<p>We merge revision 12 from trunk to B1.0 and the output of the merge shows
that a new file is added: </p>
+<p><code>1.6.6>svn merge ^/trunk branches/B1.0 -c12<br/>— Merging r12
into 'branches/B1.0':<br/>A   
branches/B1.0/A/C/nu</code></p>
+<p>But when we check the status of the working copy we see some property
changes:</p>
+<p><code>1.6.6>svn status<br/> M     
branches/B1.0<br/>A  +   
branches/B1.0/A/C/nu<br/> M     
branches/B1.0/A/D/H/psi</code></p>
+<p>Checking the diff on B1.0 alone we see that mergeinfo has been added which
describes the merge we just performed, namely r12 from trunk.  That makes
sense, it's what we just did!</p>
+<p><code>1.6.6>svn diff –depth empty branches/B1.0</code></p>
+<p><code>Property changes on:
branches/B1.0<br/>___________________________________________________________________<br/>Added:
svn:mergeinfo<br/>   Merged /trunk:r12</code></p>
+<p>But what about the property change on A/D/H/psi?</p>
+<p><code>1.6.6>svn diff branches/B1.0/A/D/H/psi</code></p>
+<p><code>Property changes on:
branches/B1.0/A/D/H/psi<br/>___________________________________________________________________<br/>Modified:
svn:mergeinfo<br/>   Merged /trunk/A/D/H/psi:r12</code></p>
+<p>Oh, it's a mergeinfo change.  But wait, we happen to know that
r12 didn't affect psi and we check the log to confirm this:</p>
+<p><code>1.6.6>svn log -v
-r12<br/>————————————————————————<br/>r12
| pburba | 2009-11-17 18:21:47 -0500 (Tue, 17 Nov 2009) | 1 line<br/>Changed
paths:<br/>   A /trunk/A/C/nu.c</code></p>
+<p>So why did the mergeinfo on psi change?  The short answer is that for
all versions of Subversion up to 1.6.x, subtree mergeinfo is always updated to
describe the merge, regardless of whether the subtree was affected by the
merge.  This was done to support easier mergeinfo elision* and for
consistency in the resulting mergeinfo between single merges of a range and
multiple individual merges amounting to the same thing (e.g. svn merge ^/trunk
branch -r 100:103 or svn merge ^/trunk branch -c101, svn merge ^/trunk branch
-c102, and svn merge ^/trunk branch -c103 would both result in the same
mergeinfo).</p>
+<p>Early on, we in the development community realized this behavior was
causing more confusion than was justified by the somewhat minor benefits. 
Surely only subtrees affected by a given merge should have their mergeinfo
updated.  There was little dissent on that point, and from a coding
perspective the change was almost laughably simple.  Unfortunately making
this change had some unforeseen consequences on subsequent merges.  I
won't go into the details here, but one of these consequences was the
potential for dramatically decreased merge performance.</p>
+<p>The good news is that ultimately we were able to preserve (and in many
cases improve) merge performance while stopping the recording of mergeinfo
changes on subtrees unaffected by a merge.  The bad news is that these
changes were extensive and will not be backported to the 1.5.x or 1.6.x
releases but rather will be available only in 1.7.</p>
+<p>In the meantime, if you are wondering if you should commit these subtree
mergeinfo changes, you should.  If you elect to revert them before
committing your merge you won't be able to use the merge
–reintegrate option any more and worse, for long lived branches you will
suffer a performance hit on subsequent merges that can easily reach intolerable
levels.</p>
+</div>
+
+<div class="h2" id="property-diffs">
+<h2>Property Diffs
+<a class="sectionlink" href="#property-diffs"
+ title="Link to this section">¶</a>
+</h2>
+<p>The svn:mergeinfo property is a versioned property and just like any other
versioned property the difference applied by a merge may include changes to or
additions of that property.</p>
+<p>For example, we might have a branch working copy with no mergeinfo at
all:</p>
+<p><code>1.6.6>svn propget svn:mergeinfo branches/B3.0 -vR</code></p>
+<p>We cherry pick a single revision from our trunk:</p>
+<p><code>1.6.6>svn merge ^/trunk branches/B3.0 -c21<br/>— Merging r21
into 'branches/B3.0':<br/>UU  
branches/B3.0/A/D/gamma</code></p>
+<p>Notice the 'U' in the second column?  A property change was
part of r21, which we can see when checking the working copy's status:</p>
+<p><code>1.6.6>svn status<br/> M     
branches/B3.0<br/>MM     
branches/B3.0/A/D/gamma</code></p>
+<p>Given the topic of this blog it's no surprise that incoming property
change was to the svn:mergeinfo property:</p>
+<p><code>1.6.6>svn propget svn:mergeinfo branches/B3.0 -vR<br/>Properties
on 'branches/B3.0':<br/>  svn:mergeinfo<br/>   
/trunk:21<br/>Properties on 'branches/B3.0/A/D/gamma':<br/> 
svn:mergeinfo<br/>   
/branches/B1.0/A/D/gamma:20<br/>   
/trunk/A/D/gamma:21</code></p>
+<p>If we check the diff of the merge source we can see that a svn:mergeinfo
property was added to trunk/A/D/gamma in r21:</p>
+<p><code>1.6.6>svn diff -r20:21 ^/trunk<br/>Index:
A/D/gamma<br/>===================================================================<br/>—
A/D/gamma   (revision 20)<br/>+++ A/D/gamma   (revision
21)<br/>@@ -1 +1 @@<br/>-the new gamma file<br/>+nc</code></p>
+<p><code>Property changes on:
A/D/gamma<br/>___________________________________________________________________<br/>Added:
svn:mergeinfo<br/>   Merged /branches/B1.0/A/D/gamma:r20</code></p>
+<p>Situations like this can happen in any number of ways, but typically
involve subtree merges (i.e. merges targeting some target below the root of a
branch) which are later merged as whole branch merges (i.e. merges targeting
the root of the branch) to some other branch.</p>
+</div>
+
+<div class="h2" id="missing-subtrees">
+<h2>Missing Subtrees
+<a class="sectionlink" href="#missing-subtrees"
+ title="Link to this section">¶</a>
+</h2>
+<p>The remaining cases all have one thing in common, subtree mergeinfo is
recorded because parts of the merge target are "missing".  They
can be missing for several different reasons, but the resulting mergeinfo is
quite similar.</p>
+</div>
+
+<div class="h3" id="shallow-working-copies">
+<h3>Shallow Working Copies
+<a class="sectionlink" href="#shallow-working-copies"
+ title="Link to this section">¶</a>
+</h3>
+<p>If you merge to shallow working copies (i.e. those set to a depth other
than infinity) then you will see subtree mergeinfo created.</p>
+<p>For example, say we check out a branch working copy at depth immediates:</p>
+<p><code>1.6.6>svn checkout <a class="warning-localfile"
href="/web/20131113041401/http://blogs.collab.net/some_url/merge_tests-1/branches/B2.0";>%ROOT_URL%/branches/B2.0</a>–depth
immediates<br/>A    B2.0/A<br/>Checked out revision
13.</code></p>
+<p>In this case the branch has no mergeinfo whatsoever:</p>
+<p><code>1.6.6>svn propget svn:mergeinfo -vR B2.0</code></p>
+<p>Now we merge all available revisions from trunk.  Since part of the
working copy is missing due to the shallow checkout we get several tree
conflicts:</p>
+<p><code>1.6.6>svn merge ^/trunk B2.0<br/>— Merging r4 through r13
into 'B2.0/A':<br/>   C B2.0/A/mu<br/>   C
B2.0/A/C<br/>   C B2.0/A/D<br/>Summary of conflicts:<br/>  Tree
conflicts: 3</code></p>
+<p>We also get new mergeinfo added to B2.0/A:</p>
+<p><code>1.6.6>svn status B2.0<br/> M     
B2.0<br/> M     
B2.0/A<br/>!     C
B2.0/A/mu<br/>      >   local missing,
incoming edit upon merge<br/>!     C
B2.0/A/C<br/>      >   local delete,
incoming edit upon merge<br/>!     C
B2.0/A/D<br/>      >   local delete,
incoming edit upon merge</code></p>
+<p><code>1.6.6>svn propget svn:mergeinfo -vR B2.0<br/>Properties on
'B2.0':<br/>  svn:mergeinfo<br/>   
/trunk:4-13<br/>Properties on 'B2.0/A':<br/> 
svn:mergeinfo<br/>    /trunk/A:4-13*</code></p>
+<p>This happens because the svn:mergeinfo property is inheritable.  Since
we don't actually have any of the children of B2.0/A in our working copy
we haven't actually merged r3:13 to them from trunk.  The
non-inheritable mergeinfo range on B2.0/A, "/trunk/A:4-13*", means
effectively that "we have merged r3:13 from trunk to this depth, but no
further".</p>
+<p>Without this non-inheritable mergeinfo on B2.0/A, if we resolved the tree
conflicts and committed this merge and then another user checked out a full
depth working copy of the branch it would appear to them that r3:13 was
completely merged to the branch, which is obviously not the case.</p>
+<p>This type of subtree mergeinfo is easily avoided if you always merge into
full depth working copies.  If you need to merge into shallow working
copies just keep this behavior in mind and be sure to commit all the subtree
mergeinfo.</p>
+</div>
+
+<div class="h3" id="shallow-merges">
+<h3>Shallow Merges
+<a class="sectionlink" href="#shallow-merges"
+ title="Link to this section">¶</a>
+</h3>
+<p>Closely related to shallow working copies are shallow merges.  Here it
is not the depth of the merge target that is shallow, but rather the depth of
the merge itself as specified with the –depth option to the merge command
(you can even do shallow merges into shallow working copies).</p>
+<p>For example, we check out a full depth working copy of a branch:</p>
+<p><code>1.6.6>svn checkout <a class="warning-localfile"
href="/web/20131113041401/http://blogs.collab.net/some_url/merge_tests-1/branches/B2.0";>%ROOT_URL%/branches/B2.0</a>/branches/B2.0
B2<br/>A    B2/A<br/>A   
B2/A/B<br/>A    B2/A/B/lambda<br/>A   
B2/A/B/E<br/>A    B2/A/B/E/alpha<br/>A   
B2/A/B/E/beta<br/>A    B2/A/B/F<br/>A   
B2/A/mu<br/>A    B2/A/C<br/>A   
B2/A/D<br/>A    B2/A/D/gamma<br/>A   
B2/A/D/G<br/>A    B2/A/D/G/pi<br/>A   
B2/A/D/G/rho<br/>A    B2/A/D/G/tau<br/>A   
B2/A/D/H<br/>A    B2/A/D/H/chi<br/>A   
B2/A/D/H/omega<br/>A    B2/A/D/H/psi<br/>Checked out revision
13.</code></p>
+<p>A shallow merge "descends" only as far as the requested depth, in
this case the to the target's immediate children:</p>
+<p><code>1.6.6>svn merge ^/trunk/A B2/A –depth immediates<br/>—
Merging r4 through r13 into 'B2/A/mu':<br/>U   
B2/A/mu</code></p>
+<p>Like a merge into a shallow working copy, non-inheritable mergeinfo is set
on the limits of what was merged to:</p>
+<p><code>1.6.6>svn status B2<br/> M     
B2<br/> M     
B2/A/B<br/>M      
B2/A/mu<br/> M     
B2/A/C<br/> M      B2/A/D</code></p>
+<p><code>1.6.6>svn propget svn:mergeinfo -vR B2<br/>Properties on
'B2':<br/>  svn:mergeinfo<br/>   
/trunk:4-13<br/>Properties on 'B2/A/B':<br/> 
svn:mergeinfo<br/>    /trunk/A/B:4-13*<br/>Properties on
'B2/A/C':<br/>  svn:mergeinfo<br/>   
/trunk/A/C:4-13*<br/>Properties on 'B2/A/D':<br/> 
svn:mergeinfo<br/>    /trunk/A/D:4-13*</code></p>
+<p>Again, this can be avoided by doing full –depth infinity merges.</p>
+</div>
+
+<div class="h3" id="switched-subtrees">
+<h3>Switched Subtrees
+<a class="sectionlink" href="#switched-subtrees"
+ title="Link to this section">¶</a>
+</h3>
+<p>If you have switched subtrees in your merge target these are treated almost
exactly the same as if those subtrees were at depth empty.  The main
difference is that the merge will record normal inheritable mergeinfo on the
root of the switched subtree, since from that point downward you do have the
full working copy (barring switched subtrees within switched subtrees, or
shallow switched subtrees, etc).</p>
+</div>
+
+<div class="h3" id="authorization-restrictions">
+<h3>Authorization Restrictions
+<a class="sectionlink" href="#authorization-restrictions"
+ title="Link to this section">¶</a>
+</h3>
+<p>Another case of "missing subtrees" is when you merge into a
working copy which you don't have full read access to.  Again you
will see non-inheritable mergeinfo added around the missing subtree.  I
suspect this is a rare occurrence, but if you suddenly see subtree mergeinfo
appearing after a merge, and none of the preceding reasons apply, this may be
the cause.</p>
+<p>* If you are unfamiliar with mergeinfo elision you can read about it here
http://www.open.collab.net/community/subversion/articles/merge-info.html.</p>
+</div>
+
+<div class="h2" id="about-the-author">
+<h2>About the author
+<a class="sectionlink" href="#about-the-author"
+ title="Link to this section">¶</a>
+</h2>
+<p>Paul Burba is a committer on the Apache Software Foundation's Subversion
project and has worked on Subversion for the past nine years. He works as a
software engineer for Collabnet from his home in New Hampshire and when not
coding he can usually be found skiing with his nephews, mountain biking with
friends, or traveling with his wife. Some time in the distant past Paul
graduated from the University of New Hampshire with a degree in Business.
Somewhat more recently he obtained a masters in computer science from Boston
University.</p>
+</div>
+
+<!-- ***************** END CONTENT ****************** -->
+</div> <!-- #site-content -->
+</body>
+</html>
Propchange:
subversion/site/staging/blog/2009-11-19-where-did-that-mergeinfo-come-from.html
------------------------------------------------------------------------------
svn:eol-style = native
Propchange:
subversion/site/staging/blog/2009-11-19-where-did-that-mergeinfo-come-from.html
------------------------------------------------------------------------------
svn:mime-type = text/html
Added:
subversion/site/staging/blog/2012-10-24-reducing_network_traffic_in_subversion_1-8.html
URL:
http://svn.apache.org/viewvc/subversion/site/staging/blog/2012-10-24-reducing_network_traffic_in_subversion_1-8.html?rev=1908741&view=auto
==============================================================================
---
subversion/site/staging/blog/2012-10-24-reducing_network_traffic_in_subversion_1-8.html
(added)
+++
subversion/site/staging/blog/2012-10-24-reducing_network_traffic_in_subversion_1-8.html
Sun Mar 26 20:17:15 2023
@@ -0,0 +1,71 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta charset="UTF-8">
+<meta http-equiv="x-ua-compatible" content="ie=edge">
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+<title>Apache Subversion Reducing network traffic in Subversion 1.8</title>
+<meta name="description" content="How to reduce network traffic using
Subversion 1.8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<link rel="manifest" href="/site.webmanifest">
+<link rel="apple-touch-icon" href="/icon.png">
+<link rel="icon" type="image/png" href="/icon.png">
+<link rel="stylesheet" href="/style/site.css" type="text/css" media="all">
+<meta name="theme-color" content="#98b0d4">
+</head>
+
+<body>
+<!--#include virtual="/site-banner.html" -->
+<!--#include virtual="/site-nav.html" -->
+<div id="site-content">
+<!--#include virtual="/site-notice.html" -->
+<!-- **************** BEGIN CONTENT ***************** -->
+
+<h1>Reducing Network Traffic in Subversion 1.8</h1>
+<div>
+<p>This article is mirrored with permission from the original location
http://blogs.collab.net/subversion/reducing_network_traffiic_in_subversion_1-8.
Inactive links has been removed or updated.</p>
+
+<p><strong>Author:</strong> C. Michael Pilato</p>
+<p><strong>Summary:</strong> Building on WC-NG released in Subversion 1.7, the
repository access module libsvn_ra_serf can significantly reduce network
traffic for <code>svn switch</code> and <code>svn update</code> if the file
contents already exist in the local pristine store.</p>
+<p><strong>Posted:</strong> 2012-10-24</p>
+
+<p><em>This post discusses Apache Subversion features which are available in
the development codebase at the time of writing but which have not yet been
published in an official release and may change prior to such a
release.</em></p>
+<p>I’ve made neither apologies about nor attempts to hide the fact that
I adore Subversion’s sparse checkouts functionality. The moment that
feature became available, I reorganized my local Subversion-versioned projects
from a scattered mess of thirty or so disparate trunk and branch working copies
into a single working copy per project, rooted at the project’s root
directory and sparsely populated from there.</p>
+<p>Now, I’ll be honest. The immediate benefit (for me, at least) was
mostly a soft one â an intangible improvement not so much to what Subversion
was doing for me, but to what I was doing in between Subversion operations. My
workspace was better organized. I spent less time trying to remember which
working copies held what. I was able to get a better big-picture view of what
was happening in the portions of the project tree that I cared about simply by
running a single update that covered all those areas. These aren’t things
you can measure with a benchmarking tool or a regression test suite â they
are measured by the increased percentage of exposed surface area of the floor
of my otherwise cluttered brain.</p>
+<p>The Subversion developers debuted sparse checkouts in Subversion 1.5, and
have improved it some in subsequent releases. For example, with Subversion 1.6
came the ability to exclude â that is, to âde-telescopeâ â existing
working copy members. Now you no longer had to scrap and rebuild working copies
which contained subtrees that no longer interested you. Improvements were also
made to Subversion’s merge and merge tracking functionality (the latter
of which was also introduced in Subversion 1.5) so that they behaved as
expected where sparsely populated working copies were involved.</p>
+<p>Subversion 1.7 brought another useful improvement to Subversion in general.
The redesign of the working copy administration area â both in terms of its
storage mechanism and its programming interface â was undertaken partly to
help inspire new feature development. WC-NG (as the new working copy concept is
called) was a major rewrite of the way working copy metadata is organized and
accessed, and as was hoped for, a couple of its characteristics caught my
attention. First, WC-NG moves all of the cached pristine text-base copies of
your versioned files into a single location, indexing them by their SHA-1
checksums. For the sake of optimizing disk usage, where there are duplicate
copies of the same content, only a single copy is kept. I’ve probably
done more development of Subversion’s repository and repository access
functionality than its client-side behaviors, so there was a certain symmetry
here that was obvious to me: Subversion repositories <em>also</em>
track file content using an index keyed on SHA-1 checksums, and <em>also</em>
try to keep only a single copy of a given ârepresentationâ of file content.
Secondly, WC-NG doesn’t preemptively purge pristine text-bases which are
no longer strictly needed (because they aren’t associated with the
current working copy state). Rather, these pristine versions accumulate over
time and users can run <code>svn cleanup</code> to force Subversion to
reconcile the stored pristine text-bases with the current working copy state
and discard the unnecessary ones.</p>
+<p>Sensing an opportunity, near the end of the Subversion 1.7 release cycle, I
taught Subversion’s mod_dav_svn Apache server module to inform clients
asking for updates (or checkouts, switches, merges, diffs, etc.) of the SHA-1
checksum of any file content it was recommending or providing to the client.
(The server has transmitted MD5 checksums of this content since before
Subversion 1.0, but we’ve been trying as a project to convert to SHA-1.)
I wasn’t sure just yet what the client would do with that information,
but it seemed valuable to me and to other Subversion developers who were
sensing the same.</p>
+<p>After Subversion 1.7 was released, I was finally able to fill in that
blank. Subversion 1.8 is projected to ship with a single HTTP repository access
module, libsvn_ra_serf. The Serf approach to HTTP communications differs from
our previous Neon-based approach in that it favors using many small, pipelined
requests instead of fewer, synchronous, monolithic ones. Checkouts and updates
performed using libsvn_ra_serf ask the server for an update report containing a
list of things the client needs to fetch from the server â a shopping list,
if you will â in order to complete the update process. In Subversion 1.7,
I’d taught the server to include in that shopping list the SHA-1 checksum
(the UPC code, if we’re continuing the analogy) of each item required.
Now, in the Subversion trunk (aka â1.8-devâ) codebase, I’ve taught
libsvn_ra_serf to take that UPC code, ask WC-NG if there are any files in the
“pristine pantry” which carry that cod
e, and â if so â source the file directly from the local pristine store
rather than asking the server for yet another copy of it. (After my initial
implementation, I also taught libsvn_ra_serf to handle MD5 checksums the same
way, effectively allowing this optimization to work against even the oldest of
supported Subversion servers.)</p>
+<p>What does all this mean? Speed.</p>
+<p>When using a Subversion 1.8 client to communicate via HTTP, circumstances
may permit you to download fewer â perhaps even zero â files over the
network. For example, if you temporarily backdate your working copy to an older
revision, then update again to the revision you were previously at, Subversion
shouldn’t have to fetch any file’s content over the wire at all.
Unless you’ve run <code>svn cleanup</code> since backdating, your working
copy administrative area still holds the pristine versions of files in that
younger revision. Similarly, if someone commits a rename of a file which you
have locally in your working copy, Subversion shouldn’t have fetch the
contents of the moved file over the wire again â a copy of those contents
already resides in your local pristine text-base store.</p>
+<p>Now, I started this post yammering on about sparse checkouts. Why?
What’s the connection? Because it’s under sparse checkouts that I
think this small little change to Subversion’s behavior really has a
chance to shine. Since the pristine data store is per-working-copy, it stands
to reason that the more sections of your repository tree which use it, the
better the chances of finding something therein that would otherwise have to be
fetched across the network. With a sparsely populated working copy, any time I
need to âsubscribe toâ, say, a new branch in my project, Subversion’s
new don’t-grab-file-content-I-already-have functionality has the entire
existing pristine store at its disposal. Subversion should only have to fetch
any files in that branch for which there are no other exact copies on any other
branch or tag in my working copy. This is very unlike a freshly checked-out
working copy devoted solely to a single branch, where the pristi
ne store is completely empty until after the checkout, forcing Subversion to
download every single file in the checkout set across the network. What’s
more, should I ever need to exclude a branch or some other specific subtree and
then restore it later, that restoration process has access to the pristine
contents of that subtree prior to its exclusion plus that of all the other
items elsewhere in the working copy from which to pull data before resorting to
wire transfer.</p>
+<p>Take for example a relatively simple yet common situation. You’re
working on your project’s trunk, and you decide that you need to create a
branch and do some of your development with a bit more isolation, but you still
want to track the trunk too. In the past, most folks would:</p>
+<ol>
+<li>Create the branch, probably using <code>svn copy URL NEW-URL</code>.</li>
+<li>Checkout a new working copy of the branch, yawning as all those files were
transferred over the wire. (Skilled Subversioneers would short-cut this by
making a local OS-level copy of their working copy directory and then using
<code>svn switch</code> to make that copy track their new branch.)</li>
+<li>Start working on the branch.</li>
+<li>Occasionally synchronize the branch with any changes that occurred on the
trunk, with any file deltas again being transferred across the wire.</li>
+</ol>
+<p>Using sparse checkouts and the pristine storage sourcing improvements,
things run similarly but without so much network traffic:</p>
+<ol>
+<li>Create the branch, probably using <code>svn copy URL NEW-URL</code>.</li>
+<li>Update to include the new branch in the sparsely populated working copy.
The content of the new branch exactly matches that of the trunk, so no file
content is transferred over the wire at all!</li>
+<li>Start working on the branch.</li>
+<li>Occasionally synchronize the branch with any changes that occurred on the
trunk, though now with file deltas being transferred across the wire only for
files changed on the branch.</li>
+</ol>
+<p>Of course, Subversion still uses the same path-based approach to access
privileges that it always has. It’s not the case that just because a user
may be able to read a file’s contents on a given branch that he or she is
now permitted to know that the same file exists in some other unreadable area
of the repository. All I’ve done is help the client avoid re-fetching
file content it already holds in the local pristine cache.</p>
+<p>As the Apache Subversion community looks to begin winding down development
activities on what will be Subversion 1.8, I’d encourage you to have a
look around the project’s public-facing materials (such as our <a
title="Subversion Roadmap" href="/roadmap.html">Roadmap page</a> and the <a
title="Subversion 1.8 Release Notes" href="/docs/release-notes/1.8.html">1.8
Release Notes</a>, both of which are works-in-progress) to see if there’s
a feature or enhancement that interests you. Perhaps you could help us test out
some of this new stuff and ensure that when it does see the light of day in an
official release, it’s the best it can be.</p>
+</div>
+
+<div class="h2" id="about-the-author">
+<h2>About the author
+<a class="sectionlink" href="#about-the-author"
+ title="Link to this section">¶</a>
+</h2>
+<p>C. Michael Pilato is a core Subversion developer, co-author of Version
Control With Subversion (O'Reilly Media), and the primary maintainer of ViewVC.
He works remotely from his home state of North Carolina as a software engineer
for CollabNet, and has been an active open source developer since early 2001.
Mike is a proud husband and father who loves traveling, soccer, spending
quality time with his family, and any combination of those things. He also
enjoys composing and performing music, and harbors not-so-secret fantasies of
rock stardom. Mike has a degree in computer science and mathematics from the
University of North Carolina at Charlotte.</p>
+</div>
+
+<!-- ***************** END CONTENT ****************** -->
+</div> <!-- #site-content -->
+</body>
+</html>
Propchange:
subversion/site/staging/blog/2012-10-24-reducing_network_traffic_in_subversion_1-8.html
------------------------------------------------------------------------------
svn:eol-style = native
Propchange:
subversion/site/staging/blog/2012-10-24-reducing_network_traffic_in_subversion_1-8.html
------------------------------------------------------------------------------
svn:mime-type = text/html
Added:
subversion/site/staging/blog/2013-06-24-repository-dictated-configuration-part-1-inheritable-properties.html
URL:
http://svn.apache.org/viewvc/subversion/site/staging/blog/2013-06-24-repository-dictated-configuration-part-1-inheritable-properties.html?rev=1908741&view=auto
==============================================================================
---
subversion/site/staging/blog/2013-06-24-repository-dictated-configuration-part-1-inheritable-properties.html
(added)
+++
subversion/site/staging/blog/2013-06-24-repository-dictated-configuration-part-1-inheritable-properties.html
Sun Mar 26 20:17:15 2023
@@ -0,0 +1,205 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta charset="UTF-8">
+<meta http-equiv="x-ua-compatible" content="ie=edge">
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+<title>Apache Subversion Mergeinfo - Understanding the internals</title>
+<meta name="description" content="Subversion 1.8 server dictated configuration
part 1 of 3: Introduction to inheritable properties">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<link rel="manifest" href="/site.webmanifest">
+<link rel="apple-touch-icon" href="/icon.png">
+<link rel="icon" type="image/png" href="/icon.png">
+<link rel="stylesheet" href="/style/site.css" type="text/css" media="all">
+<meta name="theme-color" content="#98b0d4">
+</head>
+
+<body>
+<!--#include virtual="/site-banner.html" -->
+<!--#include virtual="/site-nav.html" -->
+<div id="site-content">
+<!--#include virtual="/site-notice.html" -->
+<!-- **************** BEGIN CONTENT ***************** -->
+
+<h1>Repository Dictated Configuration — Part 1 of 3: Inheritable
Properties</h1>
+<div>
+<p>This article is mirrored with permission from the original location
http://blogs.collab.net/subversion/the-road-to-repository-dictated-configuration-day-2-autoprops.
Inactive links has been removed or updated.</p>
+
+<p><strong>Author:</strong> Paul Burba</p>
+<p><strong>Posted:</strong> 2013-06-25</p>
+
+<p>This is the first article in a series of three describing the different
configuration options that can be set in the repository.</p>
+</div>
+
+<div class="h2" id="property-inheritance">
+<h2>Property Inheritance
+<a class="sectionlink" href="#property-inheritance"
+ title="Link to this section">¶</a>
+</h2>
+<p>Even the most casual user of Subversion is likely familiar with versioned
properties. These name:value pairs of metadata are assigned to files or
directories. Some (those properties whose names begin with
â<code>svn:</code>“) are attributed special meaning by, and trigger
specific behaviors in, Subversion itself; the rest are open for definition and
interpretation by users or third-party Subversion-related tools.</p>
+<p>Up through Subversion 1.7, versioned properties typically only applied to
the file or directory they were set on. At most, a property set on a
directory might apply to the directory’s immediate children <a
class="simple-footnote" title="Experienced users might reasonably protest that
Subversion already has a property whose affects can reach further than a
directoryâs immediate children, namely the svn:mergeinfo property. You would
of course be quite right, svn:mergeinfo is inheritable, however it is a special
case with itâs own well-developed set of rules and can safely be disregarded
in this discussion of âgenericâ inheritable properties."
id="return-note-12025-1" href="#note-12025-1"><sup>1</sup></a>. The
<code>svn:ignore</code> property for example, if present on a directory,
defines a list of unversioned file patterns (in that <em>same</em> directory)
which are ignored by <code>svn status</code> and other subcommands.</p>
+<p style="padding-left: 30px"><em>From here on out we will simply talk about
“properties”, rather than differentiating between versioned and
revision properties — So just remember that throughout this series of
blogs we are talking about <strong>versioned</strong> properties! Revision
properties have no concept of inheritance.</em></p>
+<p>The <a href="/docs/release-notes/1.8.html">newly released Subversion
1.8</a> introduces the concept of inherited properties. This new feature is
quite transparent and in fact you can go about using properties just as you
always have and you might never notice any difference. This is because there
really is no such thing as an “inheritable” property or a
“non-inheritable” property — <em>all</em> properties are
potentially inheritable!</p>
+<p>What is really different in 1.8 is that, given a working copy path (or a
URL) Subversion now has a mechanism to find the properties set on that
path’s parents. This works even when the path is a working copy path
and the path’s parents are not found within the working copy. This
mechanism manifests itself with the new <code>--show-inherited-props</code>
option for the <code>svn proplist</code> and <code>svn propget</code>
subcommands.</p>
+<p>A quick example will show how this new option works.</p>
+<p style="padding-left: 30px"><em>Note: In today’s example I’ll
use nonsense custom properties. In part two and three we’ll demonstrate
some new Subversion reserved properties that actually do real work; right now I
just want to demonstrate some new core concepts.</em></p>
+<p>Say our repository has the property <code>foo</code> set on the root of the
repository and various subtrees. We can view all of these properties, their
locations, and values with a recursive <code>svn propget</code> on the root of
the repository <a class="simple-footnote" title="The --verbose option is used
here to provide nicely formatted output." id="return-note-12025-2"
href="#note-12025-2"><sup>2</sup></a>:</p>
+<pre>1.8.0>svn pg foo http://svn.example.com/repos --verbose --recursive
+Properties on 'http://svn.example.com/repos':
+Â foo
+Â Â Â bar
+Properties on 'http://svn.example.com/repos/calc':
+Â foo
+Â Â Â baz
+Properties on 'http://svn.example.com/repos/calc/trunk':
+Â foo
+Â Â Â qux
+Properties on 'http://svn.example.com/repos/paint':
+Â foo
+Â Â Â fum
+Properties on 'http://svn.example.com/repos/paint/trunk':
+Â foo
+Â Â Â zot</pre>
+<p>Now lets checkout a subtree of the repository,
<code>^/calc/trunk</code>:</p>
+<pre>1.8.0>svn co http://svn.example.com/repos/calc/trunk calc-trunk-wc
+AÂ Â Â calc-trunk-wc\doc
+AÂ Â Â calc-trunk-wc\src
+AÂ Â Â calc-trunk-wc\doc\INSTALL
+AÂ Â Â calc-trunk-wc\FAQ
+AÂ Â Â calc-trunk-wc\src\real.c
+AÂ Â Â calc-trunk-wc\src\main.c
+AÂ Â Â calc-trunk-wc\src\button.c
+AÂ Â Â calc-trunk-wc\src\integer.c
+AÂ Â Â calc-trunk-wc\Makefile
+AÂ Â Â calc-trunk-wc\README
+Â UÂ Â calc-trunk-wc
+Checked out revision 478.</pre>
+<p>Not surprisingly, a recursive <code>propget</code> on the root of the newly
checked out working copy shows only the <code>foo</code> property on the
working copy path corresponding to <code>^/calc/trunk</code>:</p>
+<pre>1.8.0>svn pg foo calc-trunk-wc --verbose --recursive
+Properties on 'calc-trunk-wc':
+Â foo
+Â Â Â qux</pre>
+<p>The same propget command, but this time with the new
<code>--show-inherited-props</code> option, shows the same property on the
working copy root path, but also reveals the <code>foo</code> properties on the
repository parents of that path:</p>
+<pre>1.8.0>svn pg foo calc-trunk-wc --verbose --recursive
--show-inherited-props
+Inherited properties on 'calc-trunk-wc',
+from 'http://svn.example.com/repos':
+Â foo
+Â Â Â bar
+Inherited properties on 'calc-trunk-wc',
+from 'http://svn.example.com/repos/calc':
+Â foo
+Â Â Â baz
+Properties on 'calc-trunk-wc':
+Â foo
+Â Â Â qux</pre>
+<p>The <code>foo</code> properties set on <code>^/paint</code> and
<code>^/paint/trunk</code> are not shown because those paths are not parents of
the working copy. The <code>svn proplist</code> subcommand also supports the
<code>--show-inherited-props</code> option and works in a similar way, except
of course that <strong>all</strong> inherited properties, regardless of name,
are revealed.</p>
+</div>
+
+<div class="h2" id="building-blocks">
+<h2>Building Blocks
+<a class="sectionlink" href="#building-blocks"
+ title="Link to this section">¶</a>
+</h2>
+<p>So now we have the inverse of a recursive propget/proplist; a way to look
‘up’ the repository tree rather than just ‘down’ it.Â
What can we do with this new found ability?</p>
+<p style="padding-left: 30px"><em>Keep in mind that all the Subversion
reserved properties that existed prior to 1.8 still only apply to the path they
are set on or, at most, that path’s immediate children <a
class="simple-footnote" title="Once again with the notable exception of
svn:mergeinfo." id="return-note-12025-3"
href="#note-12025-3"><sup>3</sup></a>. The same is likely true of any custom
properties you’ve added to your own repository — Old properties
don’t suddenly have new reach.</em></p>
+<p>That warning aside, property inheritance becomes very useful in two
cases:</p>
+<p>The first is with new Subversion reserved properties <a
class="simple-footnote" title="As of Subversion 1.8.0 the only reserved
properties which Subversion interprets as inheritable are svn:auto-props
(covered in part 2 of this blog) and svn:global-ignores (covered in part 3).
Look for more features to be built with inherited properties in future releases
of Subversion (a log message templating mechanism comes to mind). In the
meantime feel free to use the feature however youâd like. Any piece of
versioned metadata you want to apply to your whole repository (or large
subsections thereof) can easily be stored in a property on the root of your
repository (or the appropriate subtree)." id="return-note-12025-4"
href="#note-12025-4"><sup>4</sup></a> that take advantage of inheritance to
apply a property to all subtrees under the path on which the property is set.Â
In part 2 of this blog, we’ll see the first of two such properties,
<code>svn:auto-props</code>.</p>
+<p>The second case is with your own custom tools, scripts, workflows, etc.
that rely on versioned properties to drive behavior. For all of those, now
you have a new tool to work with, what you do with it is up to you — I
suspect that some of you will come up with clever applications for inheritable
properties which we never considered when developing the feature.</p>
+</div>
+
+<div class="h2" id="caveats">
+<h2>Caveats
+<a class="sectionlink" href="#caveats"
+ title="Link to this section">¶</a>
+</h2>
+<p>Before we finish for today, there are a few things to keep in mind
regarding property inheritance:</p>
+</div>
+
+<div class="h3" id="upgrading-older-working-copies">
+<h3>Upgrading Older Working Copies
+<a class="sectionlink" href="#upgrading-older-working-copies"
+ title="Link to this section">¶</a>
+</h3>
+<p>Recall how, in the example above, <code>svn propget --show-inherited-props
calc-trunk-wc</code> revealed both the properties on <code>calc-trunk-wc</code>
and those which were set on it’s parents in the repository. Subversion
accomplishes this look-up of inherited properties without contacting the
repository <a class="simple-footnote" title="In general Subversion working
copies strive to only contact the repository when absolutely necessary. This
preserves the ability to use the working copy when the repository cannot be
contacted and all other things being equal, a given operation is likely to be
faster if the repository does not need to be contacted."
id="return-note-12025-5" href="#note-12025-5"><sup>5</sup></a>. It does this
by keeping an inherited property cache in the working copy database for the
root of the working copy <a class="simple-footnote" title="Any switched paths
in your working copy count as separate working copy roots and will have their
own cache
s." id="return-note-12025-6" href="#note-12025-6"><sup>6</sup></a>. This
cache is updated whenever the working copy is, i.e. during a checkout, update,
or switch. When you upgrade an older format working copy via the ‘svn
upgrade’ command, this cache is created, but not populated. So be sure
to update your working copy after an upgrade.</p>
+<p>For example: Oops, this is an older working copy!</p>
+<pre>>svn pg foo --verbose --show-inherited-props
+svn: E155036: Please see the 'svn upgrade' command
+svn: E155036: The working copy at 'C:\SVN\calc-trunk-wc'
+is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects
format 31). You need to upgrade the working copy first.</pre>
+<p>We’ll upgrade the working copy as per the error message:</p>
+<pre>>svn upgrade</pre>
+<p>Now check for inherited props:</p>
+<pre>>svn pg foo --verbose --show-inherited-props
+Properties on '.':
+Â foo
+Â Â Â qux</pre>
+<p>Oh, that’s right, the cache needs to be populated via an update!</p>
+<pre>>svn up
+Updating '.':
+At revision 478.</pre>
+<p>Now the inherited properties are found:</p>
+<pre>>svn pg foo --verbose --show-inherited-props
+Inherited properties on '.',
+from 'http://svn.example.com/repos':
+Â foo
+Â Â Â bar
+Inherited properties on '.',
+from 'http://svn.example.com/repos/calc':
+Â foo
+Â Â Â baz
+Properties on '.':
+Â foo
+Â Â Â qux</pre>
+</div>
+
+<div class="h3" id="minimum-requirements">
+<h3>Minimum Requirements
+<a class="sectionlink" href="#minimum-requirements"
+ title="Link to this section">¶</a>
+</h3>
+<p>While you obviously need a 1.8 Subversion client, a 1.8 server is
optional. A 1.8 server may provide better performance when populating the
inherited properties cache or when using the proplist/propget subcommands
against a URL.</p>
+</div>
+
+<div class="h3" id="authorization">
+<h3>Authorization
+<a class="sectionlink" href="#authorization"
+ title="Link to this section">¶</a>
+</h3>
+<p>You can only inherit properties from repository paths which you have read
access to. If you don’t have read access to a given path it will appear
to you as if there are no properties to inherit from that path. There is no
warning or error issued in this case.</p>
+</div>
+
+<div class="h2" id="inheritance-within-the-working-copy">
+<h2>Inheritance Within the Working Copy
+<a class="sectionlink" href="#inheritance-within-the-working-copy"
+ title="Link to this section">¶</a>
+</h2>
+<p>As mentioned above, the inherited property cache only knows what properties
the root of the working copy inherits. This means that local changes and or
<a
href="https://svnbook.red-bean.com/en/1.8/svn.basic.in-action.html#svn.basic.in-action.mixedrevs";>mixed-revision
working copies</a> have no effect on what a given working copy path inherits.Â
This isn’t the place to go into the full implications of this, but keep
this simple rule in mind and you shouldn’t have any surprises: If you are
counting on having the most up-to-date value of an inherited property (from the
root of the repository for example), be sure the root of your working copy is
up-to-date.</p>
+</div>
+
+<div class="h2" id="notes">
+<h2>Notes
+<a class="sectionlink" href="#notes"
+ title="Link to this section">¶</a>
+</h2>
+<ol>
+ <li id="note-12025-1"><p>Experienced users might reasonably protest that
Subversion already has a property whose affects can reach further than a
directory’s immediate children, namely the <a
href="2008-05-06-merge-info.html"><code>svn:mergeinfo</code> property</a>. You
would of course be quite right, <code>svn:mergeinfo</code> is inheritable,
however it is a special case with it’s <a
href="2009-11-19-where-did-that-mergeinfo-come-from.html">own well-developed
set of rules</a> and can safely be disregarded in this discussion of
“generic” inheritable properties. <a
href="#return-note-12025-1">↩</a></p></li>
+ <li id="note-12025-2"><p>The <code>--verbose</code> option is used here to
provide nicely formatted output. <a
href="#return-note-12025-2">↩</a></p></li>
+ <li id="note-12025-3"><p>Once again with the notable exception of
<code>svn:mergeinfo</code>. <a href="#return-note-12025-3">↩</a></p></li>
+ <li id="note-12025-4"><p>As of Subversion 1.8.0 the only reserved properties
which Subversion interprets as inheritable are <code>svn:auto-props</code>
(covered in part 2 of this blog) and <code>svn:global-ignores</code> (covered
in part 3). Look for more features to be built with inherited properties in
future releases of Subversion (a log message templating mechanism comes to
mind). In the meantime feel free to use the feature however you’d like.
Any piece of versioned metadata you want to apply to your whole repository (or
large subsections thereof) can easily be stored in a property on the root of
your repository (or the appropriate subtree). <a
href="#return-note-12025-4">↩</a></p></li>
+ <li id="note-12025-5"><p>In general Subversion working copies strive to only
contact the repository when absolutely necessary. This preserves the ability to
use the working copy when the repository cannot be contacted and all other
things being equal, a given operation is likely to be faster if the repository
does not need to be contacted. <a
href="#return-note-12025-5">↩</a></p></li>
+ <li id="note-12025-6"><p>Any switched paths in your working copy count as
separate working copy roots and will have their own caches. <a
href="#return-note-12025-6">↩</a></p></li>
+</ol>
+</div>
+
+<div class="h2" id="about-the-author">
+<h2>About the author
+<a class="sectionlink" href="#about-the-author"
+ title="Link to this section">¶</a>
+</h2>
+<p>Paul Burba is a committer on the Apache Software Foundation's Subversion
project and has worked on Subversion for the past nine years. He works as a
software engineer for Collabnet from his home in New Hampshire and when not
coding he can usually be found skiing with his nephews, mountain biking with
friends, or traveling with his wife. Some time in the distant past Paul
graduated from the University of New Hampshire with a degree in Business.
Somewhat more recently he obtained a masters in computer science from Boston
University.</p>
+</div>
+
+<!-- ***************** END CONTENT ****************** -->
+</div> <!-- #site-content -->
+</body>
+</html>
Propchange:
subversion/site/staging/blog/2013-06-24-repository-dictated-configuration-part-1-inheritable-properties.html
------------------------------------------------------------------------------
svn:eol-style = native
Propchange:
subversion/site/staging/blog/2013-06-24-repository-dictated-configuration-part-1-inheritable-properties.html
------------------------------------------------------------------------------
svn:mime-type = text/html
Added:
subversion/site/staging/blog/2013-06-25-repository-dictated-configuration-part-2-autoprops.html
URL:
http://svn.apache.org/viewvc/subversion/site/staging/blog/2013-06-25-repository-dictated-configuration-part-2-autoprops.html?rev=1908741&view=auto
==============================================================================
---
subversion/site/staging/blog/2013-06-25-repository-dictated-configuration-part-2-autoprops.html
(added)
+++
subversion/site/staging/blog/2013-06-25-repository-dictated-configuration-part-2-autoprops.html
Sun Mar 26 20:17:15 2023
@@ -0,0 +1,249 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta charset="UTF-8">
+<meta http-equiv="x-ua-compatible" content="ie=edge">
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+<title>Apache Subversion Repository dictated configuration 2/3:
Autoprops</title>
+<meta name="description" content="">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<link rel="manifest" href="/site.webmanifest">
+<link rel="apple-touch-icon" href="/icon.png">
+<link rel="icon" type="image/png" href="/icon.png">
+<link rel="stylesheet" href="/style/site.css" type="text/css" media="all">
+<meta name="theme-color" content="#98b0d4">
+</head>
+
+<body>
+<!--#include virtual="/site-banner.html" -->
+<!--#include virtual="/site-nav.html" -->
+<div id="site-content">
+<!--#include virtual="/site-notice.html" -->
+<!-- **************** BEGIN CONTENT ***************** -->
+
+<h1>Repository Dictated Configuration — Part 2 of 3: Autoprops</h1>
+<div>
+<p>This article is mirrored with permission from the original location
http://blogs.collab.net/subversion/the-road-to-repository-dictated-configuration-day-2-autoprops.
Inactive links has been removed or updated.</p>
+
+<p><strong>Author:</strong> Paul Burba</p>
+<p><strong>Posted:</strong> 2013-06-25</p>
+</div>
+
+<div class="h2" id="automatic-properties">
+<h2>Automatic Properties
+<a class="sectionlink" href="#automatic-properties"
+ title="Link to this section">¶</a>
+</h2>
+<p>In part 1 I talked about the new inheritable properties feature in
Subversion 1.8. I promised that this feature would pave the way for
repository dictated configuration (RDC). Today I’ll show you the first
part of 1.8′s RDC related features, the new <code>svn:auto-props</code>
property.</p>
+</div>
+
+<div class="h2" id="what-is-rdc">
+<h2>Wait…What is RDC Exactly?
+<a class="sectionlink" href="#what-is-rdc"
+ title="Link to this section">¶</a>
+</h2>
+<p>Subversion provides an extensive set of <a
href="https://svnbook.red-bean.com/en/1.8/svn.advanced.confarea.html";>user
configurable options</a> which control various aspects of a Subversion
client’s operations. For repositories with only a small handful of
committers in the same location, manually synchronizing these configurations is
probably not too difficult. For larger and/or distributed groups however,
ensuring that everyone has the same configuration becomes increasingly
cumbersome. Subversion provides a mechanism to enforce some of this
configuration via <a
href="https://svnbook.red-bean.com/en/1.8/svn.reposadmin.create.html#svn.reposadmin.hooks.uses";>hook
scripts</a>. Hook scripts however, by their very nature, provide only
after-the-fact enforcement — a hook script can deny a commit to an
improperly configured user, but it won’t correct the user’s
configuration.</p>
+<p>A better solution are repository dictated <a class="simple-footnote"
title="Full disclosure: The repository âdictatedâ configurations discussed
here are truly only suggestions to well-behaved 1.8+ clients. Older clients
will obviously not understand the new dictates. Even with newer clients it is
relatively easy for a user to modify a client to ignore server-side suggestions
â Subversion is open source after all! Given this reality, server-side
enforcement of desired behaviors via hook scripts is still recommended if you
need 100% guaranteed compliance." id="return-note-12105-1"
href="#note-12105-1"><sup>1</sup></a> configurations that seamlessly supplement
the client’s configuration with repository-wide settings that apply to
operations directly on the repository and indirectly via the repository’s
working copies. One of the most commonly requested features in this realm is
for repository dictated values for automatic property setting, which Subver
sion 1.8 provides with the new reserved <code>svn:auto-props</code>
property.</p>
+</div>
+
+<div class="h2" id="autoprops-before-1-8">
+<h2>Autoprops Before 1.8
+<a class="sectionlink" href="#autoprops-before-1-8"
+ title="Link to this section">¶</a>
+</h2>
+<p><em>This is a high level refresher, for more detail see the <a
href="https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.props.auto";>Version
Control with Subversion book</a>.</em></p>
+<p>In Subversion 1.7 when you add a file to version control with the svn add
or svn import subcommands, Subversion attempts to set common properties on that
file automatically. Some of these properties (e.g.
<code>svn:executable</code>, <code>svn:mime-type</code>) are set regardless of
configuration, while others (e.g. <code>svn:eol-style</code>) <a
class="simple-footnote" title="svn:mime-type actually falls into both these
categories â it can be set via the run-time configuration, but if nothing is
defined there, then Subversion will attempt to automatically set the mime type
via a set of hard-coded rules." id="return-note-12105-2"
href="#note-12105-2"><sup>2</sup></a> depend on the particulars of your
individual run-time configuration. These configurations can be overridden at
the command line with the <a
href="https://svnbook.red-bean.com/en/1.8/svn.ref.svn.html#svn.ref.svn.sw.config_option";>–config-option</a>
and <a href="https://svnbook.red-bean.com/en/1.8/sv
n.ref.svn.html#svn.ref.svn.sw.config_dir">–config-dir</a> options.</p>
+<p>The configuration section of interest to us today is auto-props. In this
section you can define properties which automatically get set on added/imported
files. For example, say we have this configuration <a class="simple-footnote"
title="I confess to a simplification here â there isnât just a single user
configuration, it can be defined in up to 4 locations:
+
+Per-user runtime configuration
+The per-user Registry values (Windows Only)
+Per-machine runtime configuration
+The system-wide Registry values (Windows Only)
+
+Lower numbered configurations take precedence over higher numbered ones. In
this blogâs examples, for the purposes of simplicity, weâll assume configs
#2 through #4 are empty and our entire configuration is defined in #1 only."
id="return-note-12105-3" href="#note-12105-3"><sup>3</sup></a>:</p>
+<pre>### Set enable-auto-props to 'yes' to enable automatic properties
+### for 'svn add' and 'svn import', it defaults to 'no'.
+### Automatic properties are defined in the section 'auto-props'.
+<strong>enable-auto-props = yes</strong>
+
+### Section for configuring automatic properties.
+<strong>[auto-props]</strong>
+### The format of the entries is:
+###Â Â file-name-pattern = propname[=value][;propname[=value]...]
+### The file-name-pattern can contain wildcards (such as '*' and
+### '?'). All entries which match (case-insensitively) will be
+### applied to the file. Note that auto-props functionality
+### must be enabled, which is typically done by setting the
+### 'enable-auto-props' option.
+*.c = svn:eol-style=native
+*.cpp = svn:eol-style=native
+*.h = svn:keywords=Author Date Id Rev URL;svn:eol-style=native
+*.dsp = svn:eol-style=CRLF
+*.dsw = svn:eol-style=CRLF
+*.sh = svn:eol-style=native;svn:executable
+*.txt = svn:eol-style=native;svn:keywords=Author Date Id Rev URL;
+*.png = svn:mime-type=image/png
+*.jpg = svn:mime-type=image/jpeg
+Makefile = svn:eol-style=native</pre>
+<p>Given the above configuration, when we place a file with the
<code>.c</code> extension under version control, the file will automatically
have the <code>svn:eol-style</code> property set on it with a value of
<code>native</code>:</p>
+<pre>1.8.0>svn st
+?      src\panel.c
+
+1.8.0>svn add src\panel.c
+AÂ Â Â Â Â Â Â Â src\panel.c
+
+1.8.0>svn proplist src\panel.c --verbose
+Properties on 'src\panel.c':
+Â svn:eol-style
+Â Â Â native</pre>
+<p>Nice, but if we are a repository administrator, we must rely on all of our
users manually setting up their configuration this way <a
class="simple-footnote" title="Subversion sets no auto-props in its default
configuration" id="return-note-12105-4" href="#note-12105-4"><sup>4</sup></a>.Â
It would be better if there was a way to push the desired auto-prop
definitions for a repository (or a project within a repository) to the users <a
class="simple-footnote" title="i.e. Repository Dictated Configuration!"
id="return-note-12105-5" href="#note-12105-5"><sup>5</sup></a>…</p>
+</div>
+
+<div class="h2" id="the-svn-auto-props-property">
+<h2>The svn:auto-props Property
+<a class="sectionlink" href="#the-svn-auto-props-property"
+ title="Link to this section">¶</a>
+</h2>
+<p>…Enter the new <code>svn:auto-props</code> property. The value of
this new property should have the same format as the auto-props runtime
configuration option: Any number of newline separated key-value pairs in the
format FILE_PATTERN = PROPNAME=VALUE[;PROPNAME=VALUE ...]).</p>
+<p>We might have the <code>svn:auto-props</code> property set on the root of
our repository with a value very much like that in our runtime configuration
from previous example:</p>
+<pre>1.8.0>svn pg svn:auto-props http://svn.example.com/repos --verbose
+Properties on 'http://svn.example.com/repos':
+Â svn:auto-props
+Â Â Â *.c = svn:eol-style=native
+Â Â Â *.cpp = svn:eol-style=native
+Â Â Â *.h = svn:keywords=Author Date Id Rev URL;svn:eol-style=native
+Â Â Â *.dsp = svn:eol-style=CRLF
+Â Â Â *.dsw = svn:eol-style=CRLF
+Â Â Â *.sh = svn:eol-style=native;svn:executable
+Â Â Â *.txt = svn:eol-style=native;svn:keywords=Author Date Id Rev URL;
+Â Â Â *.png = svn:mime-type=image/png
+Â Â Â *.jpg = svn:mime-type=image/jpeg
+Â Â Â Makefile = svn:eol-style=native</pre>
+<p>The value of the <code>svn:auto-props</code> property defines automatic
properties for any path added or imported to a directory location which
inherits the property.</p>
+</div>
+
+<div class="h2" id="svn-auto-props-inherited-from-the-repository-root">
+<h2>Example: svn:auto-props Inherited from the Repository Root
+<a class="sectionlink"
href="#svn-auto-props-inherited-from-the-repository-root"
+ title="Link to this section">¶</a>
+</h2>
+<p>Lets look at a very simple example of how the new property works to set
automatic properties. Lets assume we have no auto-props defined in our
runtime configuration:</p>
+<pre>### Set enable-auto-props to 'yes' to enable automatic properties
+### for 'svn add' and 'svn import', it defaults to 'no'.
+### Automatic properties are defined in the section 'auto-props'.
+enable-auto-props = no</pre>
+<p>Further, lets assume our repository administrator previously set the
<code>svn:auto-props</code> property on the root of the repository <a
class="simple-footnote" title="Note that the svn:auto-props property can only
be set on directories." id="return-note-12105-6"
href="#note-12105-6"><sup>6</sup></a>:</p>
+<pre>1.8.0>svn propget svn:auto-props --verbose -R
http://svn.example.com/repos
+Properties on 'http://svn.example.com/repos':
+Â svn:auto-props
+Â Â Â *.c = svn:eol-style=native
+Â Â Â *.h = svn:eol-style=native
+Â Â Â *.py = svn:eol-style=native</pre>
+<p>We checkout a new working copy for our current project:</p>
+<pre>1.8.0>svn co http://svn.example.com/repos/calc/trunk calc-trunk-wc
+AÂ Â Â calc-trunk-wc\doc
+AÂ Â Â calc-trunk-wc\src
+AÂ Â Â calc-trunk-wc\doc\INSTALL
+AÂ Â Â calc-trunk-wc\FAQ
+AÂ Â Â calc-trunk-wc\src\button.c
+AÂ Â Â calc-trunk-wc\src\integer.c
+AÂ Â Â calc-trunk-wc\src\real.c
+AÂ Â Â calc-trunk-wc\src\main.c
+AÂ Â Â calc-trunk-wc\Makefile
+AÂ Â Â calc-trunk-wc\README
+Â UÂ Â calc-trunk-wc
+Checked out revision 480.</pre>
+<p>After doing some work, we have a new file we want to put under version
control:</p>
+<pre>1.8.0>svn st calc-trunk-wc
+?      calc-trunk-wc\src\bindings.h
+
+1.8.0>svn add calc-trunk-wc\src\bindings.h
+AÂ Â Â Â Â Â Â Â calc-trunk-wc\src\bindings.h</pre>
+<p>When we do that, sure enough, the <code>svn:auto-props</code> property,
inherited from the root of the repository, results in an automatically set
<code>svn_eol-style</code> property on the added file:</p>
+<pre>1.8.0>svn pg svn:auto-props -v --show-inherited-props
calc-trunk-wc\src\bindings.h
+Inherited properties on 'calc-trunk-wc\src\bindings.h',
+from 'http://svn.example.com/repos':
+Â svn:auto-props
+Â Â Â *.c = svn:eol-style=native
+Â Â Â *.h = svn:eol-style=native
+Â Â Â *.py = svn:eol-style=native
+
+1.8.0>svn pl -v calc-trunk-wc\src\bindings.h
+Properties on 'calc-trunk-wc\src\bindings.h':
+Â svn:eol-style
+Â Â Â native</pre>
+</div>
+
+<div class="h2" id="hierarchy-of-automatic-properties">
+<h2>Hierarchy of Automatic Properties
+<a class="sectionlink" href="#hierarchy-of-automatic-properties"
+ title="Link to this section">¶</a>
+</h2>
+<p>The previous example is probably the simplest case involving
<code>svn:auto-props</code> that you will encounter. But what happens if:</p>
+<ul>
+<li>We add <code>foo/bar.bat</code> and <code>foo</code> inherits multiple
<code>svn:autoprops</code> from different parents and those properties have
different values for the same file pattern?</li>
+<li>The runtime configuration defines yet another value for the same
pattern?</li>
+<li>We use the the <code>--config-options</code> or <code>--config-dir</code>
options?</li>
+</ul>
+<p>In those cases the following rules apply:</p>
+<p><strong>A)</strong> <strong><code>svn:auto-props</code> override the
runtime configuration’s auto-props:</strong> An automatic property, for a
given pattern, defined in <code>svn:auto-props</code> overrides the same
auto-prop for the <em>identical</em> pattern in the auto-props runtime
configuration <a class="simple-footnote" title="Either the standard runtime
configuration or that pointed to by the --config-dir option."
id="return-note-12105-7" href="#note-12105-7"><sup>7</sup></a>.</p>
+<p><strong>B)</strong> <strong>Nearer <code>svn:auto-props</code> take
precedence:</strong> If an automatic property, for the <em>same</em> pattern,
is inherited from more than one parents’ <code>svn:auto-props</code>
property, the nearer path-wise parent overrides the more distant parents.</p>
+<p><strong>C)</strong> <strong>Explicit <code>svn:auto-props</code> take
precedence over those that are inherited:</strong> An automatic property, for a
given pattern, defined in a <code>svn:auto-props</code> property explicitly set
on a path overrides the same auto-prop(s) for the identical pattern inherited
from any parents.</p>
+<p><strong>D)</strong> <strong>No guarantees if a file matches multiple
patterns:</strong> Like the auto-props runtime configuration option, if a file
matches more than one file pattern which defines a value for the same property,
then there is no guarantee which pattern’s value will be automatically
applied. For example, if and added file <code>foo.py</code> inherits both
these values,</p>
+<pre>*.py = svn:eol-style=native
+*.p* = svn:eol-style=CRLF</pre>
+<p>then there is no guarantee which eol-style will be set on the added file
<code>foo.py</code>.</p>
+<p><strong>E) <code>--no-auto-props</code> means NO automatic
properties:</strong> Like the auto-props runtime option,
<code>svn:auto-props</code> property is disregarded when using the
<code>--no-auto-props</code> option on the command line.</p>
+<p><strong>F)</strong> <strong>Disabling automatic properties in the runtime
configuration doesn’t affect RDC:</strong> <code>svn:auto-props</code> is
not disabled when the enable-auto-props runtime configuration option is set to
no.</p>
+<pre><pre>### Set enable-auto-props to 'yes' to enable automatic
properties
+### for 'svn add' and 'svn import', it defaults to 'no'.
+### Automatic properties are defined in the section 'auto-props'.
+<strong>### Note: Setting this option to 'no' has no effect on the behavior
of</strong>
+<strong>### the svn:auto-props property</strong>
+enable-auto-props = no</pre></pre><
+</div>
+
+<div class="h2" id="where-should-it-go">
+<h2>Where Should It Go?
+<a class="sectionlink" href="#where-should-it-go"
+ title="Link to this section">¶</a>
+</h2>
+<p>Remember, <code>svn:auto-props</code> is inheritable. So typically you
will only need to set the property on the root of the repository. If your
repository has several different projects that require different
configurations, then you can put the property on the root folder of each
project <a class="simple-footnote" title="Recall from part 1 that all users
must have read access to whatever directory you set svn:auto-props on,
otherwise they wonât be able to inherit from that path."
id="return-note-12105-8" href="#note-12105-8"><sup>8</sup></a>. Remember,
less is more when it comes to inherited properties — If you are setting
<code>svn:auto-props</code> such that a given repository path inherits the
<em>same</em> values from multiple parents, then you are probably doing more
than you need to.</p>
+</div>
+
+<div class="h2" id="notes">
+<h2>Notes
+<a class="sectionlink" href="#notes"
+ title="Link to this section">¶</a>
+</h2>
+<ol>
+ <li id="note-12105-1"><p>Full disclosure: The repository
“dictated” configurations discussed here are truly only
<em>suggestions</em> to well-behaved 1.8+ clients. Older clients will obviously
not understand the new dictates. Even with newer clients it is relatively easy
for a user to modify a client to ignore server-side suggestions —
Subversion<em> is</em> open source after all! Given this reality, server-side
enforcement of desired behaviors via hook scripts is still recommended if you
need 100% guaranteed compliance. <a
href="#return-note-12105-1">↩</a></p></li>
+ <li id="note-12105-2"><p><code>svn:mime-type</code> actually falls into both
these categories — it can be set via the run-time configuration, but if
nothing is defined there, then Subversion will attempt to automatically set the
mime type via a set of hard-coded rules. <a
href="#return-note-12105-2">↩</a></p></li>
+ <li id="note-12105-3"><p>I confess to a simplification here — there
isn’t just a single user configuration, it can be defined in up to 4
locations:</p>
+ <ol>
+ <li>Per-user runtime configuration</li>
+ <li>The per-user Registry values (Windows Only)</li>
+ <li>Per-machine runtime configuration</li>
+ <li>The system-wide Registry values (Windows Only)</li>
+ </ol>
+ <p>Lower numbered configurations take precedence over higher numbered
ones. In this blog’s examples, for the purposes of simplicity,
we’ll assume configs #2 through #4 are empty and our entire configuration
is defined in #1 only. <a href="#return-note-12105-3">↩</a></p></li>
+ <li id="note-12105-4"><p>Subversion sets no auto-props in its default
configuration <a href="#return-note-12105-4">↩</a></p></li>
+ <li id="note-12105-5"><p>i.e. Repository Dictated Configuration! <a
href="#return-note-12105-5">↩</a></p></li>
+ <li id="note-12105-6"><p>Note that the <code>svn:auto-props</code> property
can only be set on directories. <a
href="#return-note-12105-6">↩</a></p></li>
+ <li id="note-12105-7"><p>Either the standard runtime configuration or that
pointed to by the <code>--config-dir</code> option. <a
href="#return-note-12105-7">↩</a></p></li>
+ <li id="note-12105-8"><p>Recall from part 1 that all users must have read
access to whatever directory you set <code>svn:auto-props</code> on, otherwise
they won’t be able to inherit from that path. <a
href="#return-note-12105-8">↩</a></p></li>
+</ol>
+</div>
+
+<div class="h2" id="about-the-author">
+<h2>About the author
+<a class="sectionlink" href="#about-the-author"
+ title="Link to this section">¶</a>
+</h2>
+<p>Paul Burba is a committer on the Apache Software Foundation's Subversion
project and has worked on Subversion for the past nine years. He works as a
software engineer for Collabnet from his home in New Hampshire and when not
coding he can usually be found skiing with his nephews, mountain biking with
friends, or traveling with his wife. Some time in the distant past Paul
graduated from the University of New Hampshire with a degree in Business.
Somewhat more recently he obtained a masters in computer science from Boston
University.</p>
+</div>
+
+<!-- ***************** END CONTENT ****************** -->
+</div> <!-- #site-content -->
+</body>
+</html>
Propchange:
subversion/site/staging/blog/2013-06-25-repository-dictated-configuration-part-2-autoprops.html
------------------------------------------------------------------------------
svn:eol-style = native
Propchange:
subversion/site/staging/blog/2013-06-25-repository-dictated-configuration-part-2-autoprops.html
------------------------------------------------------------------------------
svn:mime-type = text/html
Added:
subversion/site/staging/blog/2013-06-26-repository-dictated-configuration-part-3-global-ignores.html
URL:
http://svn.apache.org/viewvc/subversion/site/staging/blog/2013-06-26-repository-dictated-configuration-part-3-global-ignores.html?rev=1908741&view=auto
==============================================================================
---
subversion/site/staging/blog/2013-06-26-repository-dictated-configuration-part-3-global-ignores.html
(added)
+++
subversion/site/staging/blog/2013-06-26-repository-dictated-configuration-part-3-global-ignores.html
Sun Mar 26 20:17:15 2023
@@ -0,0 +1,115 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta charset="UTF-8">
+<meta http-equiv="x-ua-compatible" content="ie=edge">
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+<title>Apache Subversion Mergeinfo - Understanding the internals</title>
+<meta name="description" content="Subversion 1.8 server dictated configuration
part 3 of 3: global ignores"/>
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<link rel="manifest" href="/site.webmanifest">
+<link rel="apple-touch-icon" href="/icon.png">
+<link rel="icon" type="image/png" href="/icon.png">
+<link rel="stylesheet" href="/style/site.css" type="text/css" media="all">
+<meta name="theme-color" content="#98b0d4">
+</head>
+
+<body>
+<!--#include virtual="/site-banner.html" -->
+<!--#include virtual="/site-nav.html" -->
+<div id="site-content">
+<!--#include virtual="/site-notice.html" -->
+<!-- **************** BEGIN CONTENT ***************** -->
+
+<h1>Repository Dictated Configuration — Part 3 of 3: Global Ignores</h1>
+<div>
+<p>This article is mirrored with permission from the original location
http://blogs.collab.net/subversion/repository-dictated-configuration-day-3-global-ignores.
Inactive links has been removed or updated.</p>
+
+<p><strong>Author:</strong> Paul Burba</p>
+<p><strong>Posted:</strong> 2013-06-26</p>
+
+<p>Welcome to the last topic in my three part series on repository dictated
configuration (RDC). In part 2 we talked about the new svn:auto-props
property. Today we’ll discuss the other new inherited property that
involves RDC, <code>svn:global-ignores</code>.</p>
+</div>
+
+<div class="h2" id="ignoring-unversioned-items-before-1-8">
+<h2>Ignoring Unversioned Items Before 1.8
+<a class="sectionlink" href="#ignoring-unversioned-items-before-1-8"
+ title="Link to this section">¶</a>
+</h2>
+<p><em>Once again, this is just a quick refresher, if none of this sounds
familiar, then give <a
href="https://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html";>this
section</a> of the Version Control with Subversion book a quick read.</em></p>
+<p>Up until 1.7 there were two ways to prevent the svn add and import
subcommands from adding certain items we didn’t want to place under
version control (as well as making svn status ignore such unversioned items).Â
Both of these methods still exist in 1.8:</p>
+<p>First, is the global-ignores runtime configuration option:</p>
+<pre>### Set global-ignores to a set of whitespace-delimited globs
+### which Subversion will ignore in its 'status' output, and
+### while importing or adding files and directories.
+### '*' matches leading dots, e.g. '*.rej' matches '.foo.rej'.
+global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo
__pycache__ *.rej *~ #*# .#* .*.swp .DS_Store</pre>
+<p>Second is the <code>svn:ignore</code> versioned property. This property,
which can be set on any directory, has a value which is expected to be a
newline-delimited list of file patterns that Subversion should ignore. These
patterns are appended to any ignore patterns defined in the runtime
configuration.</p>
+</div>
+
+<div class="h2" id="the-svn-global-ignores-property">
+<h2>The svn:global-ignores Property
+<a class="sectionlink" href="#the-svn-global-ignores-property"
+ title="Link to this section">¶</a>
+</h2>
+<p>In Subversion 1.8, these existing ignore mechanisms are joined by the
<code>svn:global-ignores</code> property. This new property is essentially a
more powerful version of the <code>svn:ignore</code> property. Like the
earlier property, <code>svn:global-ignores</code> can only be set on a
directory and should have as a value a set of newline delimited file patterns
<a class="simple-footnote" title="It was intended that the ignore patterns in
the svn:global-ignores property could be delimited with any whitespace (similar
to the global-ignores runtime configuration option), not just newlines (as with
the svn:ignore property), but there is a bug in 1.8.0 and only newline
separated patterns work." id="return-note-12119-1"
href="#note-12119-1"><sup>1</sup></a>. These patterns are appended to any
patterns defined in the global-ignores runtime configuration option together
with any applicable <code>svn:ignore</code> defined patterns, to determine
ignorable items. Unlike <cod
e>svn:ignore</code> however, the <code>svn:global-ignores</code> property is
inheritable and applies to all paths under the directory on which the property
is set <a class="simple-footnote" title="The caveats I mentioned about
inherited properties in part 1 still apply of course!" id="return-note-12119-2"
href="#note-12119-2"><sup>2</sup></a>, not just the immediate children of the
directory.</p>
+<p>The following short example demonstrates how this new property works.</p>
+<p>The <code>svn:global-ignores</code> patterns are themselves ignored (as are
the runtime config global-ignores and the svn:ignore property) when the
<code>--no-ignore</code> option is used. So to see all unversioned items in
our working copy, we pass that option to the status subcommand:</p>
+<pre>1.8.0>svn st --no-ignore
+?      calc\trunk\doc\README.foo
+IÂ Â Â Â Â Â calc\trunk\file.bar
+IÂ Â Â Â Â Â calc\trunk\file.baz
+IÂ Â Â Â Â Â calc\trunk\file.foo
+IÂ Â Â Â Â Â calc\trunk\file.qux</pre>
+<p>Here we see that four files are being ignored, while one (README.foo) is
unversioned by doesn’t match any ignore patterns. First, let’s
look at the svn:ignore property on calc/trunk:</p>
+<pre>1.8.0>svn pg svn:ignore -vR
+Properties on 'calc\trunk':
+Â svn:ignore
+Â Â Â *.foo
+Â Â Â *.moo</pre>
+<p>That accounts for file.foo. Then we check our runtime configuration and
find this snippet:</p>
+<pre>### Set global-ignores to a set of whitespace-delimited globs
+### which Subversion will ignore in its 'status' output, and
+### while importing or adding files and directories.
+### '*' matches leading dots, e.g. '*.rej' matches '.foo.rej'.
+global-ignores = *.qux</pre>
+<p>That accounts for file.qux. But what about file.bar and file.baz? There
can be only one option left, the new svn:global-ignores property. Sure
enough, on the root of the repository we find that property, with patterns that
account for the remaining two ignored files:</p>
+<pre>1.8.0>svn pg svn:global-ignores -v --show-inherited-props calc\trunk
+Inherited properties on 'calc\trunk',
+from '.':
+Â svn:global-ignores
+Â Â Â *.bar
+Â Â Â *.baz</pre>
+</div>
+
+<div class="h2" id="final-thoughts">
+<h2>Final Thoughts
+<a class="sectionlink" href="#final-thoughts"
+ title="Link to this section">¶</a>
+</h2>
+<p>As we discussed in part 2 regarding svn:auto-props, svn:global-ignores
should be set as high up the repository tree as is feasible. And it deserves
mention one final time: Be sure you understand the limitations of inherited
properties discussed in part 1 — and thus the limitations of RDC via
<code>svn:auto-props</code> and <code>svn:global-ignores</code>.</p>
+</div>
+
+<div class="h2" id="notes">
+<h2>Notes:
+<a class="sectionlink" href="#notes"
+ title="Link to this section">¶</a>
+</h2>
+<ol>
+ <li id="note-12119-1"><p>It was intended that the ignore patterns in the
<code>svn:global-ignores</code> property could be delimited with any whitespace
(similar to the global-ignores runtime configuration option), not just newlines
(as with the <code>svn:ignore</code> property), but there is a bug in 1.8.0 and
only newline separated patterns work. <a
href="#return-note-12119-1">↩</a></p></li>
+ <li id="note-12119-2"><p>The caveats I mentioned about inherited properties
in part 1 still apply of course! <a
href="#return-note-12119-2">↩</a></p></li>
+</ol>
+</div>
+
+<div class="h2" id="about-the-author">
+<h2>About the author
+<a class="sectionlink" href="#about-the-author"
+ title="Link to this section">¶</a>
+</h2>
+<p>Paul is a committer on the Apache Software Foundation's Subversion project
and has worked on Subversion for the past nine years. He works as a software
engineer for Collabnet from his home in New Hampshire and when not coding he
can usually be found skiing with his nephews, mountain biking with friends, or
traveling with his wife. Some time in the distant past Paul graduated from the
University of New Hampshire with a degree in Business. Somewhat more recently
he obtained a masters in computer science from Boston University.</p>
+</div>
+
+<!-- ***************** END CONTENT ****************** -->
+</div> <!-- #site-content -->
+</body>
+</html>
Propchange:
subversion/site/staging/blog/2013-06-26-repository-dictated-configuration-part-3-global-ignores.html
------------------------------------------------------------------------------
svn:eol-style = native
Propchange:
subversion/site/staging/blog/2013-06-26-repository-dictated-configuration-part-3-global-ignores.html
------------------------------------------------------------------------------
svn:mime-type = text/html
