On Sep 6, 2005, at 19:12, Dave Pawson wrote:
>> Now you work in your new working
>> copy as you normally would to work on your project, editing existing
>> files, adding new files (and using "svn add" on them to inform
>> Subversion that they should become part of the repository)
>
> I find that sort of non-intuitive.
> AFAIK, its when I do the commit that they become
> part of the 'master' repository?
> Not when I 'add' them?
When you "svn add" a file, you're informing Subversion that, when you
do your next "svn commit," you want that file to be added to the
repository. It's not immediately sent to the repository when you "svn
add." It's deferred until you "svn commit."
The idea is like this. If you have a project, and you want to
implement feature Foo, then to do so perhaps you will need to add a
new library, add a new module, modify this other library, and modify
this main file to include the new additions, say. Although you've had
to touch many parts of your project, all these changes and additions
were done to accomplish one goal: implement Foo. They should all be
checked in at the same time. So you get a working copy, implement
Foo, and then commit. The commit includes the new files you added,
and the changes to the existing files, and you give it a commit
message that says you implemented Foo, and let's say the repository
is now at revision 31. So now it's all very clear: revision 30 didn't
have Foo; revision 31 does. If you ever need to undo Foo, you can do
so by undoing a single revision (that's in the book under "undoing a
change" if you're interested). If you need to bring Foo into a branch
of your project, that's easy too.
If Subversion had instead automatically sent every change or addition
to the server as you made it, that wouldn't do anybody much good.
Maybe you've just modified the main file to include the new module,
but the module isn't done. Doesn't do anyone any good to have that in
the repository. Or maybe you've made the new library, but not
included it yet from anywhere. Not so helpful to have that in the
repository either. So Subversion lets you do your work and be the
judge of when it's finished and when it's ready to be committed to
the repository.
>> and moving
>> or renaming files (with "svn mv"), and using "svn commit" when you're
>> done with a batch of work to save it to the repository.
>
> Doesn't ' svn mv'
> move them *within* the repo?
When operating on repository URLs, yes...
svn mv url://to/repository/project/trunk/foo url://to/repository/
project/trunk/bar
...but I was talking about inside a working copy, which is probably
the way you'll want to work most of the time. The "svn mv" command
above with URLs works without a working copy, and has the effect of
doing that rename directly in the repository, and creating a new
revision right away. Usually you want to work in a working copy, so
that you can test changes, and make multiple changes at one time,
before committing when you're ready.
>> I'm surprised you had trouble after reading the book.... It was all
>> fairly clear to me after I read it,
>
> based on my prejudice, I might suggest
> you knew too much when you read it?
Honest, I had no idea what I was doing beforehand! :-)
> http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-9-sect-1.2-
> re-add
>
> says
> 'Add files, directories, or symbolic links to your working copy and
> schedule them for addition to the repository.'
> Not quite true?
Well, it's exactly true....
> My crude view is,
> move files into 'working directory' (no glossary to define this
> overloaded definition?)
Move them there, sure, if you've created them elsewhere first for
some reason. But generally I think you'll want to be creating files
directly in your working copy as you need them, then svn adding them,
then committing when you're done with a change.
A working copy (or working directory, if you like) is a local copy
(on your hard drive) of (part of) a repository, big enough for you to
do whatever task it is that you want to do with the project in the
repository. I manage web applications with my Subversion repository,
so I always check out the project's complete trunk, else it wouldn't
function. May be different for other kinds of development, or
especially for non-programming tasks. Point is, it's your own _copy_
of what's in the repository, so you can _work_ on it (hence "working
copy"). You can break it, make it unstable, do whatever work you need
to do without fear that it will inconvenience anyone else
simultaneously working on the project, and when you're done with your
task and everything works again, you can commit that change to the
repository in one atomic action.
> do an add
> do a commit
>
> that 'adds' them to the repo?
Yes. "svn add" says "this here file that I put in my local working
copy is something I would like you to upload into the repository when
next I commit," and "svn commit" says "what I've changed here in my
working copy I want you to now incorporate into the repository."
> Why is the DFDS vs Berkely db mentioned in a new install?
> It may well be significant history, but it's still history IMHO, if
> its not an issue
> with a new install?
Haven't looked at what's mentioned in the install docs...
BerkeleyDB (BDB) is a well-known database engine that has been used
by Subversion to store repository data since day 1. Such repositories
can develop problems, though, because of the way Subversion is using
BDB. File-system-based file-system (FSFS) is a new repository storage
format introduced in Subversion 1.1 and the default as of 1.2. Unless
you have specific reasons for wanting BDB, it's recommended to use
FSFS for your repositories. If you want more information on FSFS,
read here:
http://svn.collab.net/repos/svn/trunk/notes/fsfs
> I wanted to sync n machines with one set of files.
> subversion seems as if it will work out well for my needs.
Sounds like that should work, yes.
> How do I stop the server being readable by anyone using svn co <url>?
> Or was that just because I'd saved a password on my win32 box?
There are many different authentication schemes possible for Subversion.
If you're using the file:/// protocol, then the only protection is in
the filesystem's permissions.
If you're using the svn:// protocol, then there's an access file you
can set up with usernames and passwords.
If you're using the svn+ssh:// protocol, then it's handled entirely
by the operating system (set up operating system user accounts for
people to access the repository)
If you're using http:// or https://, then you can set up Apache to do
whatever kind of authentication you want (simple password files,
LDAP, etc.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 6 20:05:36 2005