[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Getting ready to adopt Subversion

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Thu, 4 Jun 2009 17:48:36 +0100

> -----Original Message-----
> From: Dallman, John [mailto:john.dallman_at_siemens.com]
> Sent: Thursday, June 04, 2009 4:55 PM
> To: users_at_subversion.tigris.org
> Subject: Getting ready to adopt Subversion
>
[snip]
> 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.

>
> 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.

>
> 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.

SVN's been good to us since we migrated from VSS. My advice for you is
to go for svn 1.5+ and use the sparse checkout feature. This is the way
I found to be closest to the VSS way of working: opening a repository
browser, selecting a directory to checkout, performing actions on it
using a menu in the repo-browser, all the time having it checkout code
into the same path as shown in the repo. (ie checkout the toplevel
directory with option 'this item only', and then on you can open the
repo browser from that directory similar to opening VSS explorer).

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).

Install using a FSFS backend.

If you decide to install on Windows, use VisualSVN - its amazingly easy
to get going, and it runs apache so all the good configuration is
available for you.

Migrating VSS to SVN - I updated a vb.net tool that did what I needed
with history and tags (on codeplex, called VSS2SVN), but there are
others. Plan on taking some time to do the migration - and remember to
run analyze with the fix things option on VSS beforehand!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2359495

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-04 18:49:55 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.