Re: Subversion and TortoiseSVN

Andy Peters wrote:
VxWorksNovice wrote:

The only negative is it can be quite slow when there are a large number of
files in your repository. I am using the 'native file system' for the
repository rather than the 'database' option, and suspect this is the cause.
There were some warnings about using the database on network shares, so I
kept to the native file system to be safe.

The biggest positive is the ease with which it is installed and maintained.
We are not using an SVN server at all, and am not sure why you would ever
want to unless you want to use a WEB browser to view the repository. We
just have Tortoise client installations. Although the server package is
installed on one machine this is just to get access to the backup utility
(hotcopy), the server itself is not running.

Most users don't report significant slowdowns as the repository grows.
Perhaps it's the file-system access you're using, instead of the
server?


According to the subversion website, the database backend can be faster at finding the latest version of the repository when you have very large numbers of versions saved - I think this is a minor issue. Other than that, if you have a large repository, you will get a large number of files in each directory. Different file systems are better or worse in such cases. For example, FAT32 can get very slow when you have lots of files in a directory (it's not ordered, so the search is linear), as can ext2 on linux, while NTFS is better and reiserfs is virtually unaffected by the number of files in the directory.

Almost nobody uses the file:/// option (which is what you're using if
you're not using either of the server options). One Real Good
Argument in favor of a server option (either the simpler svnserve or
the more-flexible server using apache) is that you don't have to mount
the repository drive on every user's machine (which is generally a
security no-no). When using the file:/// access, each user has to
have permission to write to the server files and it's easy to screw
things up. Using svnserve or apache, only one "user" (usually
svnowner) has write access to the repository. In other words, users
interact with the server and only the server is allowed to actually
update the repository.


Agreed - while your svn client software might not corrupt the database accessible as a file share, other software (or the user) on the client PC could do so accidentally. It's fine for a small (single machine) svn setup, but for anything more, it is best to coordinate through an svn server.

Also, the server mechanisms allow the admin person to set up
permissions regarding what users are allowed to commit changes to the
repo and who's allowed to only view it.

-a

.

Relevant Pages

  • Re: problem with a DTS "Analysis Services Processing Task"
    ... "Darren Gosbell" wrote: ... Server A from Server B, then this is not the issue. ... database that you are trying to process. ... Where is your Olap Repository located? ...
    (microsoft.public.sqlserver.olap)
  • Re: problem with a DTS "Analysis Services Processing Task"
    ... Where is your Olap Repository located? ... If you repository is in a SQL database (especially if that database is ... not stored on Server "B"), check that the SQLOper user has access to ... Administrators" privilege. ...
    (microsoft.public.sqlserver.olap)
  • RE: Events Every 5 minutes (Userenv 1090, 1104)
    ... corruption in the repository for the Windows Management Instrumentation ... try rebuilding the WMI Repository using the following steps: ... Stop the Windows Management Instrumentation service, ... enable and start the "Collect Server ...
    (microsoft.public.windows.server.sbs)
  • Re: Offline update
    ... server is isolated and not able to go out on the web to RHN? ... *) Use another host with external access as a RHEL mirror, using "reposync" to mirror the entire download repository channels. ... which has a far more reliable software downlod and repository mirroring capability and has fundamental software compatibility with RHEL. ... The software channels and their associated DRM are one of the most irritating aspects of RHEL: even the recent "yum-rhn-plugin" in RHEL 5 is actually "up2date", wearing granny's nightgown, and ignores basic features of yum such as channel-specific configuration files to provide channel-specific "exclude" ...
    (linux.redhat)
  • Re: SAP JCo Wiederverbinden
    ... das Du fuer das Initialisieren ... This is caused by either a) erroneous server settings, ... Konstruktor wird der ClientPool wieder hinzugefügt, ein Repository ... Wie gesagt ist der Clientpool nicht notwendig. ...
    (de.comp.lang.java)
Loading