RE: general questions

Thanks again, I'm learning.

I appreciate the time put in to help me and I really don't want to cost
you more time, so I have a couple of yes/no questions.

So the only time to use svnadmin create without having a dedicated
server would be a single user (like me at home)?

As for as the dll extensions, those are not a concern. I am talking
about ide setting files. And if we have a project made up of 44
repositories I need to enter the command 44 times, no eaiser way, right?

Thanks again.

John

________________________________

From: Mark Phippard [mailto:markphip_at_gmail.com]
Sent: Monday, September 10, 2012 12:35 PM
To: John Maher; users_at_subversion.apache.org
Subject: Re: general questions

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/