How do I pass parameters to a batch file?

"A. When you call a batch file, you can enter data after the command that the batch file refers to as %1, %2, etc. For example, in the batch file hello.bat, the following command
@echo hello %1 boy

would output
hello john boy

if you called it as
hello john

The following table outlines how you can modify the passed parameter.
Parameter Description
%1 The normal parameter.
%~f1 Expands %1 to a fully qualified pathname. If you passed only a filename from the current directory, this parameter would also expand to the drive or directory.
%~d1 Extracts the drive letter from %1.
%~p1 Extracts the path from %1.
%~n1 Extracts the filename from %1, without the extension.
%~x1 Extracts the file extension from %1.
%~s1 Changes the n and x options’ meanings to reference the short name. You would therefore use %~sn1 for the short filename and %~sx1 for the short extension.

The following table shows how you can combine some of the parameters.
Parameter Description
%~dp1 Expands %1 to a drive letter and path only.
%~sp1 For short path.
%~nx1 Expands %1 to a filename and extension only.

To see all the parameters in action, put them into the batch file testing.bat, as follows.
@echo off
echo fully qualified name %~f1
echo drive %~d1
echo path %~p1
echo filename %~n1
echo file extension %~x1
echo short filename %~sn1
echo short file extension %~sx1
echo drive and directory %~dp1
echo filename and extension %~nx1

Then, run the file with a long filename. For example, the batch file run on the file c:\temp\longfilename.long would produce the following output.
fully qualified name c:\TEMP\longfilename.long
drive c:
path \TEMP\
filename longfilename
file extension .long
short filename LONGFI~1
short file extension .LON
drive and directory c:\TEMP\
filename and extension longfilename.long

This method also works on the second and subsequent parameters. You simply substitute the parameter for 1 (e.g., %~f2 for the second parameter’s fully qualified path name).

The %0 parameter in a batch file holds information about the file when it runs and indicates which command extensions you can use with the file (e.g., %~dp0 gives the batch file’s drive and path)." windowsitpro.com

svn:externals

"This assumes that your project layout looks something like this:

project/
branch/
production/
tag/
trunk/

* In the top of your project trunk, execute the following:

svn propedit svn:externals .

* This will open an editor session. In the file opened by your editor, each line indicates a different external svn repo to pull. The first segment of the line is the directory where you want the pull to exist. The last segment is the svn repo URL to pull. You can have an optional middle argument indicating the revision to use. Some examples:
o Pull framework repo from head:

framework http://framework.zend.com/svn/framework/trunk

o Pull framework repo from revision 2616:

framework -r2616 http://framework.zend.com/svn/framework/trunk

* After saving and exiting, update the repo:

svn up

* Commit changes:

svn commit

One thing to note: any directory you specify for an svn:externals checkout should not already exist in your repository. If it does, you will get an error like the following:

svn: Working copy 'sharedproject' locked
svn: run 'svn cleanup' to remove locks
" weierophinney.net

After that add default username for svn host (because we do not have username of external repository)

• Linux

vi ~/.ssh/config
Host svn.wn.d-o-m.org
User <svnuser>

• Windows - set default username for <svn-host> via putty

I got an error saying "This client is too old to work with working copy '...' ". How can I fix it without upgrading Subversion?

"Sometimes the working copy metadata format changes incompatibly between minor releases. For example, say you have a working copy created with Subversion 1.4.4, but one day you decide to try out Subversion 1.5.0. Afterwards, you attempt to switch back to 1.4.4, but it doesn't work — it just gives the above error.

This is because 1.5.0 upgraded your working copy format to support some new features (in this case, changelists, the keep-local flag, and variable-depth directories). Although 1.4.4 doesn't know anything about these new features, it can at least recognize that the working copy format has been upgraded to something higher than it can handle.

1.5.0 upgraded the working copy for a good reason: it realizes that 1.4.4 does not know about these new features, and that if 1.4.4 were to meddle with the working copy metadata now, important information might be lost, possibly causing corruption (see issue #2961, for example).

But this automatic upgrade behavior can be annoying, if you just want to try out a new release of Subversion without installing it permanently. For this reason, we distribute a script that can downgrade working copies when doing so is safe:

http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py

Run that script with the "--help" option to see how to use it. As future versions of Subversion are released, we will try to keep this FAQ entry up-to-date with potential downgrade scenarios and their implications." subversion.tigris.org