On Jun 4, 2009, at 11:48, Bolstridge, Andrew wrote:
> John Dallman wrote:
>
>> The Linux server is SLES10sp2, which comes with SVN 1.3. Is it still
>> sane to use this old-ish version? I appreciate it may not be optimal,
>> but we are not very demanding, and it's easier than building a new
>> version.
>
> You can get the latest subversion build for SLES10 -
> http://software.opensuse.org/search type in subversion, and it'll
> return
> you svn 1.6.2-5.1 rpms. I would seriously recommend using a later
> release than 1.3 - that's ancient, so much has been added since that
> you'd never get a decent answer if you ran into problems using it.
Many bugs have been fixed since Subversion 1.3 so I too recommend you
use a newer version.
>> I'd like to double-check that having CVS and SVN on the same server,
>> dealing with entirely separate repositories, is OK, and that there
>> aren't any ways for them to clash.
>
> I would think you'd be ok here. Would you run svn using svnserve or
> apache? If you use a web-browser to view the repositories, you may run
> into some config issues unless you have the 2 servers on different
> apache vhosts or locations.
If you use a web browser to view the repositories, you presumably
have installed some tool to let you do this, for example ViewVC. I
would be surprised if ViewVC didn't have a mechanism for setting it
up to access more than one repository. Even if it does not, I'm sure
you can install multiple instances of ViewVC, one for each thing you
want to view.
>> I'd also like to check on just how platform-independent a SVN
>> repository is. Can one just move the directory tree from Linux and
>> run
>> it with a Windows SVN, or is there more to it than that? We
>> understand
>> the line-endings issues thoroughly.
>
> Apparently not, you can move a repo from linux to linux and pretend
> nothing's changed, but the official way to move is to dump and load
> the
> repository. Alternatively you can use svnsync to make a backup on a
> different platform, if you ever want to change to using that as the
> primary server, you'll have a repo setup and ready to go just by
> relocating your working copy urls.
I think he was asking about moving a working copy, not moving a
repository.
You already know about the line-ending issues when moving a working
copy: if you have files with svn:eol-style set to native, and you
check out on linux, the files will have LF line endings. If you move
the working copy to a Windows machine, which expects CRLF line
endings, you'll run into problems.
Another platform difference is the handling of symlinks. If you check
in symlinks from Linux, you'll get symlinks when you check out on
Linux, but a text file if you check out on Windows. Subversion does
not support the concept of symlinks on Windows. (I understand recent
versions of Windows have "junctions" or something equivalent to
symlinks, but Subversion does not support them at this time.)
> Other advice: make sure you have a good set of ignores, svn does not
> allow you to remove files you've added by mistake. After one colleague
> checked in over a gig of pdb, pch and obj files, I added a pre-commit
> hook to ensure such files do not get added again. (the usual ignore
> list
> of files are held on the client, not the server, so you do not have
> central control over the configuration).
Yes, a good idea.
> Install using a FSFS backend.
I recommend that as well. Note that repositories created in
Subversion 1.2.0 and later will be FSFS by default. You would have to
deliberately use the "--fs-type bdb" argument to change that.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2359548
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-05 00:19:54 CEST