Source string Read only

(itstool) path: sect3/para
Context English State
<prompt>%</prompt> <userinput>svn merge -c -179454 ROADMAP.txt</userinput>
<prompt>%</prompt> <userinput>svn commit</userinput>
This can also be done directly in the repository:
<prompt>%</prompt> <userinput>svn merge -r179454:179453 svn+ssh://</userinput>
It is important to ensure that the mergeinfo is correct when reverting a file to permit <command>svn mergeinfo --eligible</command> to work as expected.
Reverting the deletion of a file is slightly different. Copying the version of the file that predates the deletion is required. For example, to restore a file that was deleted in revision N, restore version N-1:
<prompt>%</prompt> <userinput>svn copy svn+ssh://</userinput>
<prompt>%</prompt> <userinput>svn commit</userinput>
or, equally:
<prompt>%</prompt> <userinput>svn copy svn+ssh:// svn+ssh://</userinput>
Do <emphasis>not</emphasis> simply recreate the file manually and <command>svn add</command> it—this will cause history to be lost.
Fixing Mistakes
While we can do surgery in an emergency, do not plan on having mistakes fixed behind the scenes. Plan on mistakes remaining in the logs forever. Be sure to check the output of <command>svn status</command> and <command>svn diff</command> before committing.
Mistakes will happen but, they can generally be fixed without disruption.
Take a case of adding a file in the wrong location. The right thing to do is to <command>svn move</command> the file to the correct location and commit. This causes just a couple of lines of metadata in the repository journal, and the logs are all linked up correctly.
The wrong thing to do is to delete the file and then <command>svn add</command> an independent copy in the correct location. Instead of a couple of lines of text, the repository journal grows an entire new copy of the file. This is a waste.
Using a Subversion Mirror
There is a serious disadvantage to this method: every time something is to be committed, a <command>svn relocate</command> to the main repository has to be done, remembering to <command>svn relocate</command> back to the mirror after the commit. Also, since <command>svn relocate</command> only works between repositories that have the same UUID, some hacking of the local repository's UUID has to occur before it is possible to start using it.
Checkout from a Mirror
Check out a working copy from a mirror by substituting the mirror's <acronym>URL</acronym> for <literal>svn+ssh://</literal>. This can be an official mirror or a mirror maintained by using <command>svnsync</command>.
Setting up a <application>svnsync</application> Mirror
Avoid setting up a <application>svnsync</application> mirror unless there is a very good reason for it. Most of the time a <command>git</command> mirror is a better alternative. Starting a fresh mirror from scratch takes a long time. Expect a minimum of 10 hours for high speed connectivity. If international links are involved, expect this to take four to ten times longer.
One way to limit the time required is to grab a <link xlink:href="">seed file</link>. It is large (~1GB) but will consume less network traffic and take less time to fetch than svnsync will.
Extract the file and update it:
<prompt>%</prompt> <userinput>tar xf svnmirror-base-r261170.tar.xz</userinput>
<prompt>%</prompt> <userinput>svnsync sync file:///home/svnmirror/base</userinput>
Now, set that up to run from <citerefentry><refentrytitle>cron</refentrytitle><manvolnum>8</manvolnum></citerefentry>, do checkouts locally, set up a svnserve server for local machines to talk to, etc.
The seed mirror is set to fetch from <literal>svn://</literal>. The configuration for the mirror is stored in <literal>revprop 0</literal> on the local mirror. To see the configuration, try:
<prompt>%</prompt> <userinput>svn proplist -v --revprop -r 0 file:///home/svnmirror/base</userinput>
Use <literal>svn propset</literal> to change things.
Committing High-<acronym>ASCII</acronym> Data
Files that have high-<acronym>ASCII</acronym> bits are considered binary files in <acronym>SVN</acronym>, so the pre-commit checks fail and indicate that the <literal>mime-type</literal> property should be set to <literal>application/octet-stream</literal>. However, the use of this is discouraged, so please do not set it. The best way is always avoiding high-<acronym>ASCII</acronym> data, so that it can be read everywhere with any text editor but if it is not avoidable, instead of changing the mime-type, set the <literal>fbsd:notbinary</literal> property with <literal>propset</literal>:
<prompt>%</prompt> <userinput>svn propset fbsd:notbinary yes</userinput>
Maintaining a Project Branch


User avatar None

New source string

FreeBSD Doc / articles_committers-guideEnglish

New source string 4 months ago
Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/para
Source string location
String age
4 months ago
Source string age
4 months ago
Translation file
articles/committers-guide.pot, string 384