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

Re: SVN best practice: organising the SVN vault and organising your project

From: TM <tm_at_tm.uklinux.net>
Date: 2007-04-13 12:03:24 CEST

Ryan,

Thanks for your recommendations.

The USB-pen thing is just a quick way of getting round the fact that I
currently do not have a working SVN server at work which I can access
remotely.

Having said that, I have recently organised a VPN so I can now remotely
access my work files. I might try to setup a svnserver on my PC and
tunnel the remote access through the VPN.

Cheers,
TM

Ryan Schmidt wrote:
> On Apr 13, 2007, at 04:05, TM wrote:
>
>> I understand the potential pitfalls with using the 'file:' method to
>> access a vault on the intranet. The idea is that it's just a temporary
>> measure so that I am able to introduce Subversion to a (very) limited
>> number of people with minimum hassle.
>
> I understand, but we have recently seen problems on this list from
> people who tried serving a repository to multiple users via
> file-protocol access and a network share, and they encountered errors
> they should not have. The solution ended up being moving the repository
> to a locally-attached disk and running a server process like svnserve. I
> would hate for impressionable members of your organization to get a bad
> impression of Subversion simply because of the way it was set up with a
> network disk.
>
>
>> I only have local admin rights to my own PC. This means that I would
>> need to persuade the sys admin to set up a SVN server on the intranet.
>> As I mentioned before, the company uses CVS, and so organising a SVN
>> server is not so straightforward (politically). I could (and I have
>> done it in the past) set up a server on my own PC and let people
>> access the server. I might go with that option.
>
> I recommend it. I believe you will find that to be a more-stable option.
>
>
>> But this doesn't really answer my original question: how do you cope
>> with the absolute path of 'svn:externals' if you want to mirror the
>> SVN vault?
>
> Ah, sorry, I didn't see that original question. I'll quote it again to
> refresh my memory:
>
> On Apr 11, 2007, at 09:08, TM wrote:
>
>> The trouble starts when I sync my current (open) projects and vault at
>> work with the USB pen (by the way, I use Unison). I then sync the
>> files in the USB pen with my laptop.
>>
>> The problem is that I have to have mirrored all the folder structure
>> on my laptop in order for things to run smoothly. If I place the vault
>> somewhere else in my laptop (which I would like to do) then the
>> absolute URLs in the 'svn:externals' don't work.
>>
>> Also, if I decide to do some work in Linux (the laptop is
>> dual-booting), how do I mirror the location of the vault (there is no
>> C: drive in the first place)?
>
> Your terminology "sync" and "mirror" was confusing me; I thought you
> were talking about using svnsync or something but now I see you're not.
>
> Absolute svn:externals definitions are of course a problem when you need
> to switch the repository URL, such as if you change from one protocol to
> another, or from one hostname to another. Unfortunately, absolutely is
> the only way in which svn:externals can currently be specified, so it's
> best to minimize the number of times that you need to make such changes.
> That means deciding on a server name and protocol and sticking with it.
>
> Your setup sounds awfully confusing. I'm not entirely clear because of
> your terminology, but it sounds like you're talking about moving your
> repositories (what you're calling "vaults") around on disk, and even
> across several disks and machines -- from a Windows hard disk to a USB
> drive to a Linux machine -- and expecting it to continue working
> transparently. This is not really how Subversion was intended to be
> used. You're free to do that with your working copies, of course, and
> that works well, but a repository should stay put. It would be much
> better if you would pick one place on one server to put your
> repositories and then always access them via a server URL like
> svn://svn.example.com/svn/repo1 . If you need to access them from
> several locations (like from home and work), then you'll want this
> machine to be accessible via the Internet (i.e. not hidden behind an
> intranet firewall).
>
>
> You also said in your earlier message that you have each project and
> library in its own repo:
>
>> a) I use SVN for a lot of stuff. I have different vaults organised in
>> a way that makes sense from the point-of-view of how I organise things
>> in my head (e.g unrelated projects might have different vaults). All
>> vaults are organised under the common folder 'C:\vault\svn' (nearly
>> all the work is done under MS Windows).
>>
>> b) I write code in C and I have developed a few libraries that are
>> used by different projects. The libraries have their own SVN vault.
>>
>> c) Each project (under SVN) calls the required libraries using
>> 'svn:externals' (which use absolute paths pointing to the vault with
>> the libraries)
>>
>> d) The structure of a C/C++ project might look like:
>> project |- src
>> |- include
>> |- library 1
>> |- library 2
>> So, the *.h, *.c/*.cpp files of each library sit inside the
>> appropriate sub-folder (I think this is a must imposed by
>> 'svn:externals').
>>
>> So far so good (unless people think I should be including the
>> libraries in some other, better, way).
>
> Many people are happy with one-repo-per-project and others (like myself)
> are happy with one-repo-for-everything. The one thing I will say in
> favor of one-repo-for-everything is that if you ever have a new library
> that's based on an older library, or a common change that needs to be
> done in multiple projects, then you'll wish you had everything in one
> repository so you could use "svn copy" to copy the old library, and "svn
> merge" to propagate changes between the two projects. You can't copy or
> merge between multiple repositories.
>
>
> --
> To reply to the mailing list, please use your mailer's Reply To All
> function
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 13 12:03:48 2007

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.