Subversion/Tortoise questions

6 views
Skip to first unread message

Phil Pinkerton

unread,
Nov 9, 2010, 4:30:33 PM11/9/10
to us...@subversion.apache.org
1) Does Tortoise just send command to the Subversion Windows Command
Line client?

2) Can the Tortoise and/or Subversion Windows Command Line client be
configured to reduce and/or eliminate with small pack CIFS traffic
that occurs during the check out process to a Windows network drive?

-maybe "trust" the check out and run an update status as a
separate operation to get the status information validated

-turn off the status feature during the check out and then turn it on

-other options (i.e. ini or xml) file the client use to turn the
client or other specific knowledge you have about the client we can
tune

3) Are there options around the Export which is very fast but does not
write out any of the .svn file that we can use to speed up the client
and get our status information?

4) Is the another GUI Subversion client that has better performance
when content is being checked out to a Windows network drive.

5) Does Tortoise and/or Subversion Windows Command Line client
installed on the server allow multiple (i.e. 30 to 50) users accessing
the one installation at the same time to check out, check in, and
update content without corrupting content or experiencing great
performance degradation?

6) Does Subversion other customers, example scripts or configurations
for using a Subversion client with Windows network dr

Andy Levy

unread,
Nov 9, 2010, 4:56:49 PM11/9/10
to Phil Pinkerton, us...@subversion.apache.org
On Tue, Nov 9, 2010 at 16:30, Phil Pinkerton <pcpin...@gmail.com> wrote:
> 1) Does Tortoise  just send command to the Subversion Windows Command
> Line client?

No, it is not a wrapper. TortoiseSVN is built on top of the Subversion
client libraries.

> 2) Can the Tortoise and/or Subversion Windows Command Line client be
> configured to reduce and/or eliminate with small pack CIFS traffic
> that occurs during the check out process to a Windows network drive?

No. The next-generation WC format (coming with 1.7) may improve
performance, but Subversion checkout operations are very I/O
intensive. Some filesystems handle it better than others.

>     -maybe "trust" the check out and run an update status as a
> separate operation to get the status information validated
>
>     -turn off the status feature during the check out and then turn it on

TortoiseSVN's TSVNCache by default does not check network drives.

>     -other options (i.e. ini or xml) file the client use to turn the
> client or other specific knowledge you have about the client we can
> tune
>
> 3) Are there options around the Export which is very fast but does not
> write out any of the .svn file that we can use to speed up the client
> and get our status information?

Not if you want to maintain the connection to the repository.

> 4) Is the another GUI Subversion client that has better performance
> when content is being checked out to a Windows network drive.

You won't find much variation, because they almost all use the same
core libraries or code.

> 5) Does Tortoise and/or Subversion Windows Command Line client
> installed on the server allow multiple (i.e. 30 to 50) users accessing
> the one installation at the same time to check out, check in, and
> update content without corrupting content or experiencing great
> performance degradation?

Can you rephrase this? I can't tell if you're asking about 30 people
logged onto one server (via Terminal Services/RDP?) simultaneously, or
30 people accessing the same repository from their individual
workstations.

> 6) Does Subversion other customers, example scripts or configurations
> for using a Subversion client with Windows network dr

Your question got cut off.

Generally it's recommended that WCs not be located on network shares,
partly for performance reasons, partly for practicality (IOW, why have
dozens of copies of the same stuff on one fileserver, when you don't
need it all backed up and it's 95% identical in the first place?).

Phil Pinkerton

unread,
Nov 9, 2010, 5:39:16 PM11/9/10
to Andy Levy, us...@subversion.apache.org

5) Basically what I'd like to know is whether multiple instances of
the client running on the same machine maintain completely separate
data areas (i.e. - the separate instances don't interfere with each
other). If the code is re-entrant, then separate instances of the
commands will be complete separate from each other - the only thing
they share is the executable code.

6) Does Subversion other customers, example scripts or configurations

for using a Subversion client with Windows network drive?

--
" The fundamental principle here is that the justification for a
physical concept lies exclusively in its clear and unambiguous
relation to the facts that it can be experienced"   AE

Please Feed and Educate the Children... it's the least any of us can do.

Nico Kadel-Garcia

unread,
Nov 9, 2010, 7:33:32 PM11/9/10
to Phil Pinkerton, us...@subversion.apache.org
On Tue, Nov 9, 2010 at 4:30 PM, Phil Pinkerton <pcpin...@gmail.com> wrote:
> 1) Does Tortoise  just send command to the Subversion Windows Command
> Line client?
>
> 2) Can the Tortoise and/or Subversion Windows Command Line client be
> configured to reduce and/or eliminate with small pack CIFS traffic
> that occurs during the check out process to a Windows network drive?
>
>     -maybe "trust" the check out and run an update status as a
> separate operation to get the status information validated
>
>     -turn off the status feature during the check out and then turn it on
>
>     -other options (i.e. ini or xml) file the client use to turn the
> client or other specific knowledge you have about the client we can
> tune
>
> 3) Are there options around the Export which is very fast but does not
> write out any of the .svn file that we can use to speed up the client
> and get our status information?

Check out to local disk, then directly copy that to a CIFS share. This
cuts the time for a 1 Gig working copy by a factor of 10. Maintaining
an upstream checkout repository that you can CIFS duplicate is also
feasible, but tricky if updates occur in the midst of copying.

CIFS is *not good* for Subversion checkouts of any significant size.
There is no available solution to this problem in the Subversion
world.

Phil Pinkerton

unread,
Nov 10, 2010, 9:33:39 AM11/10/10
to Andy Levy, us...@subversion.apache.org
On Tue, Nov 9, 2010 at 4:56 PM, Andy Levy <andy...@gmail.com> wrote:

What about SvnAnt ?

Ludwig, Michael

unread,
Nov 10, 2010, 9:45:07 AM11/10/10
to us...@subversion.apache.org
> >> 4) Is the another GUI Subversion client that has better performance
> >> when content is being checked out to a Windows network drive.
> >
> > You won't find much variation, because they almost all use the same
> > core libraries or code.
>
> What about SvnAnt ?

SvnAnt uses the svnClientAdapter.jar, which in turn uses one of:

(1) JavaHL - Java/JNI to C++ core library interface [1]
(2) SvnKit - pure Java implementation [2]
(3) command line client, for example [3]

Performance should be best for JavaHL.

But a network drive is a network drive.

And the current working copy format generates many files.

Michael

[1] http://subclipse.tigris.org/svnant.html
[2] http://svnkit.com/
[3] http://www.sliksvn.com/

Phil Pinkerton

unread,
Nov 10, 2010, 12:08:20 PM11/10/10
to Ludwig, Michael, us...@subversion.apache.org

With regards to the Windows Subversion Client. If several scripts are
using the Subversion Command line client is the client shared or is a
separate client launched when separate scripts are ran at the same
time ?

Phil Pinkerton

unread,
Nov 10, 2010, 12:14:28 PM11/10/10
to Andy Levy, us...@subversion.apache.org
On Tue, Nov 9, 2010 at 4:56 PM, Andy Levy <andy...@gmail.com> wrote:
> On Tue, Nov 9, 2010 at 16:30, Phil Pinkerton <pcpin...@gmail.com> wrote:
>> 1) Does Tortoise  just send command to the Subversion Windows Command
>> Line client?
>

snip ...


>> 5) Does Tortoise and/or Subversion Windows Command Line client
>> installed on the server allow multiple (i.e. 30 to 50) users accessing
>> the one installation at the same time to check out, check in, and
>> update content without corrupting content or experiencing great
>> performance degradation?
>
> Can you rephrase this? I can't tell if you're asking about 30 people
> logged onto one server (via Terminal Services/RDP?) simultaneously, or
> 30 people accessing the same repository from their individual
> workstations.

Updated comment clarification from internal client:
We have not ruled out a Citrix solution at this point so finding out
how the GUI tool (TortoiseSVN ) will behave would be a good idea too.
I think Citrix takes care of all the multi-threading complexities in
this configuration but it would be good to ask. So the 30 people
would be either running scripts on the developer server of have a
Citrix session but either way the 30 people would be accessing the
Subversion client installed on the development server.

Ludwig, Michael

unread,
Nov 10, 2010, 12:59:59 PM11/10/10
to us...@subversion.apache.org
> > SvnAnt uses the svnClientAdapter.jar, which in turn uses one of:
> >
> > (1) JavaHL - Java/JNI to C++ core library interface [1]
> > (2) SvnKit - pure Java implementation [2]
> > (3) command line client, for example [3]

> With regards to the Windows Subversion Client. If several scripts are


> using the Subversion Command line client is the client shared or is a
> separate client launched when separate scripts are ran at the same
> time ?

Not entirely sure I understand your question.

As far as I can see (using ant -verbose), a new svn.exe (or just "svn" on UNIX) is spawned for each subcommand of <svn> within one script.

Which svn command line client (of possibly several ones installed on a system) is actually invoked by svnClientAdapter depends on what's available in your PATH environment variable.

I would have thought that supplementing the path by setting java.library.path in ANT_OPTS as follows would also work, but apparently it doesn't:

set PATH=D:\Opt\Ant\bin
set ANT_OPTS=-Djava.library.path=C:\Programme\SlikSvn\bin

That's probably because java.library.path is for libraries and not for executables.

Michael

Reply all
Reply to author
Forward
0 new messages