Please keep replies on the mailing list.
On Mon, Sep 10, 2012 at 12:02 PM, John Maher <JohnM_at_rotair.com> wrote:
> Thanks again Mark, you have been helpful. Let me clear some things up.**
> **
>
> ** **
>
> Let me clear up by what I mean as “local” repository. We have a svn
> server which has repositories on it. It serves us files to our local
> directories when we ask for them using VisualSVN Server. I also created
> some repositories “locally” with svnadmin create. The repositories are on
> the same machine, on the same drive as the working copy and I can get a
> working copy without any network access and do not need VisualSVN Server,
> Subversion Edge or any other server to create or access it. Sure you can
> say the server is MyMachineName and the client is MyMachineName. However
> the repositories ARE different because svnadmin works with one type and
> fails with another. Perhaps you never used the second type. If you have
> what would you call it to differentiate between them?
>
They are just repositories. You can say you are accessing one via file://
protocol and one via http:// protocol if you like.
svnadmin only operates directly on the file system via the OS. It does not
talk to anything except the bytes on disk. So it needs access to those
bytes. The normal thing to do is to run svnadmin on the server where you
want your repositories to live. You login to the server directly using
something like an SSH terminal or a Remote Desktop.
When you run a GUI on your server like VisualSVN or SVN Edge, those tools
are simply providing a way to run the svnadmin command via some other
remote access interface such as your web browser.
> I am still wondering about the issue I read somewhere it said you should
> use a what-ever-you-want-to-call-it repository via a URL and a server
> product (like VisualSVN Server) instead of a what-ever-you-want-to-call-it
> repository on a network drive without using a server product (using
> svnadmin create) in a multi-user environment.
>
You can create repositories on a network share and access them via file://
protocol but you shouldn't. All users need full read/write access to the
repository files if you do this, which means they can accidentally delete
or corrupt those files. Of course they can also do so for
malicious/intentional reasons. Accessing the repository this way will also
typically be significantly slower than accessing them via a server.
And we have numerous files we need to ignore. We are using visual studio.
> We have a project which consists of 44 dlls. Each dll is in its own
> directory and is a project in and of itself. Each directory contains files
> and directories which need to be ignored when a new user creates a working
> copy so the user’s settings don’t get stepped on. So that means entering
> the svn:ignore command 44 times at least for this one project alone. I was
> hoping for a better way.
>
You can setup clients to ignore the DLL extensions always, but that has to
be done on each client. Setting svn:ignore is the better way and it only
has to be done by one user and then committed to the repository for all
others.
> We do have TortiseSVN. The documentation is quite poor with this product.
>
Well, I disagree. At least compared to every other SVN client, they have
the best and most complete documentation. I cannot speak to the commercial
clients, maybe some of them are better but I doubt it.
That is the reason I am reading the book, which is NOT an easy read by
> the way, unless of course you already know the subject.
>
I think it is an easy read. That is how I learned Subversion. I was
coming from an AS/400 background where version control is quite different.
I had used PVCS and SourceSafe quite a bit, and CVS a little bit. From
reading the book when Subversion 1.0 came out, I felt like I understood the
tool almost immediately. Obviously there was still a lot more I learned
over the years by experience and this mailing list, but the book laid the
ground work. Understanding things like repositories, working copies,
revisions and mixed revision working copies are all essential concepts and
I think the book explains them well.
The book jumps around worse than a bullfrog on a blacktop in the summer.
> It talks about creating a repository, then goes on about properties. I am
> trying to follow it but then have to change chapters because creating
> repositories is discussed in other places AFTER you need them to exist to
> test out properties.
>
The book is open source so feel free to suggest and contribute ideas for
improvements. It is obviously difficult to strike the right balance for
giving a high level explanation of the tool and how it works, as well as
comprehensive reference documentation AND cookbook like how-to. I think it
does a great job with the high-level, is fairly good for reference material
and only lightly wades into the cookbook area with some of the examples.
That said, there is a ton of the cookbook type information in blogs and
articles on the web now so it is not hard to find it.
> I did find the hooks directory on the server, the VisualSVN server just
> doesn’t show them.
>
I believe they have a free and commercial version so maybe they only have
this in the UI for the commercial version? It ought to be possible to edit
the files in the hooks folder and have them work either way. Subversion
Edge is free (and open source) and provides it via web UI.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-09-10 18:35:55 CEST