The following executables are in C:\svn\bin right now:
SubWCRev.exe
SubWCRevCOM.exe
TortoiseBlame.exe
TortoiseIDiff.exe
TortoiseMerge.exe
TortoisePlink.exe
TortoiseProc.exe
TortoiseUDiff.exe
TSVNCache.exe
Am I looking in the wrong place? Is there some known problem with the
install? I also tried re-installing and selecting "Repair" but still
no svnserve.exe. I confirmed that all features were selected during
the install process.
The files that I used to install were:
TortoiseSVN-1.6.10.19898-win32-svn-1.6.12(2).msi and
TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi
Any help would be appreciated.
--Dan Morenus
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2658960
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
On 14 September 2010 07:47, Dan Morenus <dmor...@san.rr.com> wrote:
> I had been using 1.5.5 for some time though I hadn't tried to run
> svnserve.exe. I upgraded to 1.6.10, and later downgraded back to
> 1.5.5, and in both cases I could not find svnserve.exe. I am running
> Windows XP SP3. I installed in C:\svn and expected to find
> svnserve.exe in C:\svn\bin but it is not there.
>
The svnserve.exe is part of the command line client for Subversion,
which is a separate product, not provided by the TSVN team.
TortoiseSVN is a Windows GUI client for subversion.
Command line clients can be obtained from various sources. Start at
subversion.apache.org and look for the binary downloads for your
platform.
--
Regards,
Jean-Marc
--
. ___
. @@ // \\ "De Chelonian Mobile"
. (_,\/ \_/ \ TortoiseSVN
. \ \_/_\_/> The coolest Interface to (Sub)Version Control
. /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2659056
Oh my! I really was clueless! Thanks!
--Dan
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2659899
We use TortoiseSVN and SVN since 4 years and for some time we meet problems of performance on the developers computers when update copy.
During the first update of working directory of developers it takes several minutes to make the operation of update, then during the day and following updates there is no more this deadline.
Have you an idea on the origin of the problem
Sébastien
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2659934
I see the effect here, too, and I guess this is an effect of caching. You can
assume that after startup of your workstation, the content of your WC isn't
cached by your OS. Similarly, on the server side, the content of the
repository isn't cached either in the morning as it was probably thrown out
during the night when it wasn't used for some time and memory was used for
different things like backups.
All in all, this means that a lot of disk access has to take place, first on
the client side, to read the current the state of the WC and lock it, then on
the server side, to actually retrieve the changes from the database.
I'd do two things:
1. Use small working copies, in particular don't check out the whole
repository into one working copy.
2. Wait for SVN 1.7, where the working copy handling is supposed to be
improved in many aspects. Since the metadata is only stored in a single
location there, SVN doesn't have to recursively crawl through the directories
of a working copy in order to collect its current state, which should perform
better.
Further, you could try to prime the cache. On the server, you could run a
cronjob that accesses the repository in order to keep its data cached. On the
client, you could run a similar script on startup that just checks the state,
similar to TSVN's checking for modifications.
Uli
--
ML: http://tortoisesvn.tigris.org/list_etiquette.html
FAQ: http://tortoisesvn.net/faq
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2659988
One of the strengths of Subversion is that its commits are atomic (all or nothing). That means that the client has to gather the current state of the working copy, check with the server if there are any subsequent changes, and then finally make the commit. Arguably, the first step in the process does produce the lion's share of the commit. Apparently, Subversion 1.7 is addressing this very issue.
The effects of the performance issues are made worse the larger the working copy is, and the more changes in the working copy between commits.
A peculiarity of Windows that also affects SVN (and consequently TortoiseSVN) is how the file system works with directories. Windows and Unix file systems are optimized very differently. On Windows, it is slower to traverse directories, and handles several files in the same directory much better than Unix. With Unix the story is reversed--faster to traverse directories and slower in directories with lots of files.
NOTE: this is at the file system level--the file explorer may add delays trying to present all the files to you. Bottom line is that if your project has a deep hierarchy of directories (which is required for Java projects) SVN will be held up by the Windows file system as it's trying to gather the current state of the local repository.
The server side configuration affects step number 2. Check out the SVN manual for more information on server side configuration:
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html#svn.reposadmin.basics.backends
Both of the things I presented here are things that Tortoise isn't responsible for, but can explain some of your frustrations. Every release of Windows changes how they cache files, and how long those files remain resident in memory. But with a base understanding of what can cause these slowdowns you might come up with alternative ways of improving performance without relying on the cache.
Hi all,
Sébastien
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2659934
Confidentiality Note: The information contained in this message, and any attachments, may contain proprietary and/or privileged material. It is intended solely for the person or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2660246