Author: dsahlberg Date: Sun Mar 26 20:17:15 2023 New Revision: 1908741 URL: http://svn.apache.org/viewvc?rev=1908741&view=rev Log: In site/staging: Preserve a number of blog articles from CollabNet. The articles have been retrieved from the original source and/or archive.org. The content is unchanged except for markup changes (font => css, h2/h3 linkable etc.).
Discussed in private@ (including permissions to copy this material from CollabNet/Digital.ai): https://lists.apache.org/thread/8zlozkp8xg33zlt2ortvhl6x3gmb6bvo Approved-by: cmpilato, markphip Added: subversion/site/staging/blog/2006-09-10-EnhancingSubversionServer.html (with props) subversion/site/staging/blog/2007-06-13-merge_auditing.html (with props) subversion/site/staging/blog/2008-03-29-merging-from-foreign-repositories.html (with props) subversion/site/staging/blog/2008-05-06-merge-info.html (with props) subversion/site/staging/blog/2009-11-19-where-did-that-mergeinfo-come-from.html (with props) subversion/site/staging/blog/2012-10-24-reducing_network_traffic_in_subversion_1-8.html (with props) subversion/site/staging/blog/2013-06-24-repository-dictated-configuration-part-1-inheritable-properties.html (with props) subversion/site/staging/blog/2013-06-25-repository-dictated-configuration-part-2-autoprops.html (with props) subversion/site/staging/blog/2013-06-26-repository-dictated-configuration-part-3-global-ignores.html (with props) subversion/site/staging/blog/2013-06-28-foreign-repository-copies.html (with props) Modified: subversion/site/staging/blog/index.html Added: subversion/site/staging/blog/2006-09-10-EnhancingSubversionServer.html URL: http://svn.apache.org/viewvc/subversion/site/staging/blog/2006-09-10-EnhancingSubversionServer.html?rev=1908741&view=auto ============================================================================== --- subversion/site/staging/blog/2006-09-10-EnhancingSubversionServer.html (added) +++ subversion/site/staging/blog/2006-09-10-EnhancingSubversionServer.html Sun Mar 26 20:17:15 2023 @@ -0,0 +1,106 @@ +<!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>Enhancing a Subversion Server</h1> +<div> +<p>This article is mirrored with permission from the original location https://www.open.collab.net/community/subversion/articles/EnhancingSubversionServer.html. Inactive links has been removed or updated. Information was current as of Subversion 1.4 and some parts may not apply to current versions.</p> + +<p> When managing a Subversion server for a number of related projects, in an Open Source community or an enterprise, one needs to strike a useful balance between standardizing the development environment to the extent needed for effective collaboration while leaving enough flexibility to individual teams to work in a variety of ways. Individuals and projects will request particular features or customizations’ with some regularity. This article discusses when to customize, how to customize, and suggests a recommended approach to such requests. </p> + +<p>The first and most important question is when to customize. Many software engineers and projects have a natural tendency to adapt, or customize, their tools and environment to their likes, dislikes, and needs. They often feel strongly about particular customizations and push for them, not necessarily properly considering or quantifying the costs for themselves, their project, or the organization or community at large. As long as a customization only impacts an individual, you could arguably assert that it is only one person’s problem and responsibility. However, when it impacts multiple people, a project, or the organization at large, you must balance the benefits against the costs.</p> +</div> + +<div class="h2" id="the-cost-of-customization"> +<h2>The Cost of Customization +<a class="sectionlink" href="#the-cost-of-customization" + title="Link to this section">¶</a> +</h2> +<p>The obvious cost is the amount of effort needed to create and maintain the customization. It has to be written, tested, and maintained as the environment evolves. In addition, a customization increases the threshold to accessing data: customizations change the behavior of tools and practices and use of the tool, effectively making it more difficult for an outsider to understand, participate in, and contribute to a project. Also, each customization needs to be supported if users have issues with it. In other words, every customization makes it more expensive to operate and maintain the server, increases the threshold for users to collaborate, and adds to the variety of functionality that needs to be supported.</p> +<p>Therefore, there must be either a tangible benefit to the vast majority of projects or a significant benefit to a few projects. Note that the former is arguably not so much a customization but more a request for (and early prototyping of) a feature users want. The latter is arguably a customization that is too specific for the majority of users.</p> +</div> + +<div class="h2" id="how-to-customize"> +<h2>How to Customize +<a class="sectionlink" href="#how-to-customize" + title="Link to this section">¶</a> +</h2> +<p>There is a variety of ways to extend the functionality that Subversion already provides. The options can be classified into two flavors: Client-side or server-side customizations.</p> +</div> + +<div class="h2" id="client-side-wrappers"> +<h2>Client side - Wrappers +<a class="sectionlink" href="#client-side-wrappers" + title="Link to this section">¶</a> +</h2> +<p>Client-side customizations are solutions in which the server remains unchanged, and the customization is done on the client side by wrapping either the command-line client or client-side API calls. Client-side customizations keep the burden of customization on the individual or project requesting it, and forces the requestors to do a proper, honest, cost-benefit analysis as to whether the customization is really wanted or needed. Also, wrappers scale very well in terms of the number of customizations that can be handled: the number of people maintaining the wrappers scales with the customizations.</p> +<p>An example of a client-side customization is <a href="http://www.orcaware.com/svn/wiki/Svnmerge.py";>svnmerge.py</a>, a Python script on top of the standard Subversion command-line client that allows users to easily merge changes from and to a branch, automatically recording which change sets have already been merged. It can display an always updated list of changes yet to be merged and prevents merge mistakes, such as merging the same change twice. The svnmerge.py script is essentially an early prototype of the merge tracking functionality that is currently being discussed, designed, and implemented for a future release of Subversion.</p> +</div> + +<div class="h2" id="server-side-hook-scripts"> +<h2>Server Side - Hook Scripts +<a class="sectionlink" href="#server-side-hook-scripts" + title="Link to this section">¶</a> +</h2> +<p>Server-side customizations are solutions where the server configuration is changed. Server-side customizations scale in terms of rolling out a customization to all projects on the server. They touch the day-to-day operation of the site and increase the effort and cost of operating the service. Also, they potentially impact the security, availability, and performance of the service.</p> +<p>The primary example of server-side customizations are hook scripts. A hook, or hook script, is a program triggered by some repository event, such as creating a new revision or the modifying of an unversioned property. Each hook is handed enough information to tell what that event is, what target(s) it operates on, and the username of the person who triggered the event. Depending on the hook's output or return status, the hook program may continue the action, stop it, or suspend it in some way. The Version Control with Subversion book <a href="http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.create.hooks";>describes this in more detail</a>.</p> +<p>Subversion currently defines nine hooks: </p> +<ul> + <li class="cn_bullet">The <em>start-commit</em> hook is invoked before a transaction is created in the process of doing a commit.</li> + <li class="cn_bullet">The <em>pre-commit</em> hook is invoked after a transaction has been created but before it is committed.</li> + <li class="cn_bullet">The <em>post-commit</em> hook is invoked after a transaction is committed. </li> + <li class="cn_bullet">The <em>pre-revprop-change</em> and <em>post-revprop-change</em> hooks are invoked before respectively after a revision property is added, modified, or deleted. </li> + <li class="cn_bullet">The <em>pre-lock</em> and <em>post-lock</em> hooks are invoked before respectively after an exclusive lock on a path is created. </li> + <li class="cn_bullet">The <em>pre-unlock</em> and <em>post-unlock</em> hooks are invoked before respectively after an exclusive lock is destroyed.</li> +</ul> +<br /> +<p>Hooks are typically used for three kinds of functionality: </p> +<ul> + <li class="cn_bullet">First, to log or notify interested parties about an event. For example, sending an e-mail message per commit, summarizing key information about that commit such as the author, date, commit message, and the change set.</li> + <li class="cn_bullet">Second, to check a particular condition. For example, verify whether the code complies within coding guidelines or whether the user has the appropriate access rights to the parts of the repository that he wants to commit to.</li> + <li class="cn_bullet">Third, to block certain behavior. For example, allow a user to change a log message but not the author and date of a revision (to maintain traceability), prevent locks from being stolen, or allow locking if and only if the path has the svn:needs-lock property set.</li> +</ul> +<br /> +<p>Note that, at present, Subversion does not support a hook performing pre- or post-processing functionality, such as automatically ensuring the code complies with coding guidelines, because the server does not have a means to communicate such changes back to the client. In other words, whatever a hook does, it does not modify the transaction itself. Instead, it can check a condition and accept or reject the action.</p> +<p>Hooks are essentially a way of running arbitrary code on the server in response to actions by the version-control client. Moreover, a hook runs with the same permissions as the web server in general and, with that, has the ability to affect other repositories on the same server. This mechanism is very powerful but has potential implications on the security, availability, and performance of the server. A hook can easily slow down or bring down your server or, even worse, corrupt the data in the repository.</p> +</div> + +<div class="h2" id="findings-and-recommendations"> +<h2>Findings and Recommendations +<a class="sectionlink" href="#findings-and-recommendations" + title="Link to this section">¶</a> +</h2> +<p>When managing a Subversion server for a number of projects, you need to strike a useful balance between standardizing the environment to enable effective collaboration and efficient operation, while leaving enough flexibility to projects to work in a variety of ways. Standardization can bring many benefits, such as a reduced time to learn the environment when switching projects and enabling more effective collaboration between teams. However, a one-size-fits-all is neither feasible nor desirable with today's heterogeneity (in local culture, departmental culture, processes, and so on) in individuals and project teams.</p> +<p>From a technical perspective, client- and server-side customizations differ in what they can and can not do:</p> +<ul> + <li class="cn_bullet">Client-side customizations are suitable when it affects only a single user or for automatic pre-processing (such as code formatting).</li> + <li class="cn_bullet">Server-side customizations are suitable when the change should be standardized across the repository <em>and</em> is a notification, a check, or blocking certain behavior.</li> +</ul> +<br /> +<p>From a cost-benefit perspective, try to keep customizations that are specific to only a limited set of users on the client side. This puts the burden of customization on the project, stimulating them to make a proper and honest cost-benefit analysis, as well as preventing it from impacting others. Generic customizations that are relevant to and requested by a large percentage of the projects fit better on the server side. Server-side customizations typically have a substantially higher cost, mainly because they potentially impact performance, availability, and security of the entire server. They need rigorous testing, both upon creation and with each upgrade of the server.</p> +<p>Especially when deploying hooks, we <em>strongly</em> recommend using only <a href="http://svn.apache.org/repos/asf/subversion/trunk/contrib/";>very commonly used hooks</a>, both to mitigate the risks (the more a hook is used, the more it is tested) and to strike a reasonable balance between standardization and customization: hooks are popular if and only if they contribute value to many people and, with that, are worth the effort. Requests for esoteric customizations are likely not worth the effort of creating, testing, and maintaining.</p> +</div> + +<!-- ***************** END CONTENT ****************** --> +</div> <!-- #site-content --> +</body> +</html> Propchange: subversion/site/staging/blog/2006-09-10-EnhancingSubversionServer.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: subversion/site/staging/blog/2006-09-10-EnhancingSubversionServer.html ------------------------------------------------------------------------------ svn:mime-type = text/html Added: subversion/site/staging/blog/2007-06-13-merge_auditing.html URL: http://svn.apache.org/viewvc/subversion/site/staging/blog/2007-06-13-merge_auditing.html?rev=1908741&view=auto ============================================================================== --- subversion/site/staging/blog/2007-06-13-merge_auditing.html (added) +++ subversion/site/staging/blog/2007-06-13-merge_auditing.html Sun Mar 26 20:17:15 2023 @@ -0,0 +1,67 @@ +<!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>Merge Auditing in Subversion 1.5</h1> +<div> +<p>This article is mirrored with permission from the original location http://blogs.collab.net/subversion/2007/06/merge_auditing_.html. Inactive links has been removed or updated.</p> + +<p><strong>Author:</strong> Mark Phippard</p> +<p><strong>Posted:</strong> 2007-06-13</p> + +<p>We had a really nice addition to the Subversion merge tracking feature committed to trunk last week. <a href="https://www.hyrumwright.org/";>Hyrum Wright</a> is a student participating in the Google <a href="https://code.google.com/soc/";>Summer of Code</a> program. He has signed up to provide “Merge Auditing” features for merge tracking. You can see some details on what this means in the <a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html";>functional specifications</a>, but essentially it is about adding intelligence and awareness of the merge tracking information to the svn log and blame output. In the <a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/index.html";>merge tracking planning</a>, this has been slated as a post-1.5 feature. It is a feature everyone really wants to see in the code-base, but it was just felt that shipping the release and the core functionality had to be the priority.</p> +<p>Anyway, in this case it appears we will be able to <a href="https://en.wikipedia.org/wiki/Have_one's_cake_and_eat_it_too">have our cake and eat it too</a>. Hyrum, whom I should add is already a <a href="http://svn.apache.org/repos/asf/subversion/trunk/COMMITTERS";>full Subversion committer</a>, has made great progress on adding this support to the svn log command and has committed those changes to trunk. Additionally, it turns out that the sample repository we created for our Merge Tracking Early Adopter program really helped to work out the kinks in this feature. Since we had a nicely documented sample repository, and matching graphic, that Hyrum could refer to, it made it easier for him to refine the feature and get it working properly.</p> +<p>[Images missing as of 2023-03-19:<br/>Original url http://blogs.open.collab.net/photos/uncategorized/2007/06/13/repo.gif and http://blogs.collab.net/subversion/files/2007/06/merge-auditing.gif]</p> +<p>The above picture is the history of our sample repository. If you take a close look, the r14 commit to trunk is an interesting example where this feature comes into play. This commit is a merge from a branch, and the merge also contains additional merges from another branch. If I run this command (note the new -g option):</p> +<pre>svn log -g -r 14 $REPOS/trunk</pre> +<p>Here is the new output:</p> +<pre>------------------------------------------------------------------------r14 | merger | 2007-05-30 15:48:11 -0400 (Wed, 30 May 2007) | 3 lines + +Merge branch b - product roadmap and update about page + +Command executed: svn merge $REPOS/branches/b------------------------------------------------------------------------r13 | buser | 2007-05-30 15:46:48 -0400 (Wed, 30 May 2007) | 1 lineResult of a merge from: r14 + +Update info about our company------------------------------------------------------------------------r12 | merger | 2007-05-30 15:45:19 -0400 (Wed, 30 May 2007) | 3 linesResult of a merge from: r14 + +Merge branch a - product roadmap + +Command executed: svn merge $REPOS/branches/a------------------------------------------------------------------------r11 | auser | 2007-05-30 15:43:00 -0400 (Wed, 30 May 2007) | 1 lineResult of a merge from: r14, r12 + +Add product roadmap------------------------------------------------------------------------</pre> +<p>Note how it includes information on the revisions that were merged in r14, and additionally how one of those revisions was the result of another merge. Graphical clients like our CollabNet Desktop – Eclipse Edition and <a href="https://tortoisesvn.net/";>TortoiseSVN</a> should be able to do really useful and interesting presentations of this information in their UI.</p> +<p>This is fantastic work Hyrum. Keep it up. I cannot wait to see the blame implementation come together.</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>Mark Phippard is an engineering manager for several teams at CollabNet, including CloudForge, Subversion, Subversion Edge, Git and our Desktops and Integrations.</p> +<p>Project owner for the Subclipse project, which provides Subversion support in Eclipse. Also a full committer for the Subversion project.</p> +<p>Product owner for GitEye, Subversion Edge and the CollabNet Desktops and Integrations.</p> +</div> + +<!-- ***************** END CONTENT ****************** --> +</div> <!-- #site-content --> +</body> +</html> Propchange: subversion/site/staging/blog/2007-06-13-merge_auditing.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: subversion/site/staging/blog/2007-06-13-merge_auditing.html ------------------------------------------------------------------------------ svn:mime-type = text/html Added: subversion/site/staging/blog/2008-03-29-merging-from-foreign-repositories.html URL: http://svn.apache.org/viewvc/subversion/site/staging/blog/2008-03-29-merging-from-foreign-repositories.html?rev=1908741&view=auto ============================================================================== --- subversion/site/staging/blog/2008-03-29-merging-from-foreign-repositories.html (added) +++ subversion/site/staging/blog/2008-03-29-merging-from-foreign-repositories.html Sun Mar 26 20:17:15 2023 @@ -0,0 +1,53 @@ +<!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>Merging from Foreign Repositories</h1> +<div> +<p>This article is mirrored with permission from the original location http://blogs.collab.net/subversion/do-not-post-mer. Inactive links has been removed or updated.</p> + +<p><strong>Author:</strong> C. Michael Pilato</p> +<p><strong>Posted:</strong> 2008-03-29</p> + +<p>For many folks, the forthcoming Subversion 1.5 release gets billed as something like "merge tracking and some other stuff". It’s probably true that the work put into the new merge tracking feature outweighs the investments in other individual areas. But of course, Subversion 1.5 isn’t about merge tracking alone. There are several other major features coming in this release. And as you’d expect, the Subversion community has made countless bugfixes over the past year-and-a-half, too. But today I want to briefly talk about one half-bugfix, half-feature, that might have slipped in under your radar: merges from foreign repositories.</p> + +<p>Subversion has for some time now allowed you â kinda, sorta â to perform merge operations where the sources of the merge live in one repository but the target working copy (the thing you are merging <em>to</em>) comes from a different ("foreign") repository. After all, since Subversion models merges as essentially the application of a diff, you might expect that the source of those diffs wouldn’t matter all that much. But this is a feature that nobody really talks about: the Subversion <a href="/docs/api/latest">public API</a> doesn’t mention it; the <a href="https://svnbook.red-bean.com/";>Subversion book</a> doesn’t mention it; Subversion’s release notes don’t brag about it. In fact, the only reason I even knew the feature existed was because of code comments I came across while hacking on Subversion’s merge tracking feature. Why the shroud of secrecy? Well, it might be one of those accidental features â the ones that weren’t specifically intended to work, but mostly did anyway. Or perhaps the reason is that it only worked sometimes. At any rate, merges from foreign repositories is practically a hidden feature.</p> +<p>Apparently empowered by the spirit of "by golly this ought to work", one openCollabNet community member found this feature, though <em>and</em> found its shortcomings. User "argeman" posted the following to the merge-tracking beta program forums:</p> +<blockquote><p>i have tested the svn 1.5 alpha2 a bit (converted some repositories and played around with those). it works completely great until now. The only thing that is still not working (it never worked in previous subversion-releases): If i try to merge changes from a different repository, that will not work for added files.</p> +</blockquote> +<p>I’d never really played with merges from foreign repositories myself, but immediately recognized the value of the feature. I can summarize it in two words: "vendor branches". Vendor branches are a common way of maintaining private customizations to somebody else’s code without mirroring that code change-for-change. There are different ways to make this work. For example, you might use individual branches which are pure mirrors of a given vendor’s release package contents, and then another branch which contains the currently employed version of the vendor package plus your private modifications. Your upgrade your customized package by applying the diffs between pure vendor releases to your customized copy. Alternatively, you might keep in a version control branch only the customized copy of the vendor package, and use diffs generated as patches between unversioned vendor package contents to upgrade that branch. And some masochists avoid the powers of ve rsion control altogether and simply maintain custom patch files which need to be updated with each new release of the vendor’s package. (If you’re one of those, there are people who can help you deal with your illness.)</p> +<p>The ability to merge from foreign Subversion repositories, then, provides a sort of hybrid approach similar to the first and second methods I previously mentioned. In this approach, you need to maintain only that single customized copy of the vendor’s package instead of also tracking pure mirrors of the vendor’s release (because the pure versions can be readily obtained from the vendor’s Subversion repository). But now you get to use version control tools to merge the differences between those pure versions into your customized copy, instead of dealing with messy patch files.</p> +<p>Unfortunately, "argeman" wasn’t posting to say, "Hey, I just found this feature and it works great!" The post was to tell us that the feature had potential, but failed to handle files which needed to be added as a result of the merge. Here, however, is the joy of working on open source software. It took me all of 40 minutes to change Subversion’s code to fix the problem and compose a regression test, plus some additional time thereafter doing some related follow-up fixes. So when Subversion 1.5 ships, I expect merges from foreign repositories to be supported at the same basic level that intra-repository merges are. Renames in the merge source will still cause the same complications that they always have in Subversion, and the merge tracking logic will be bypassed when merging from foreign repositories, but the merge should complete successfully in the commonmost situations.</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/2008-03-29-merging-from-foreign-repositories.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: subversion/site/staging/blog/2008-03-29-merging-from-foreign-repositories.html ------------------------------------------------------------------------------ svn:mime-type = text/html
