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 11:48:14 2007