Thanks for the explanations Ryan.
I just hope others learn from it too!
On 06/09/05, Ryan Schmidt <subversion-2005@ryandesign.com> wrote:
> 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."
OK. it's saying 'Add them next time there is a delivery' :-)
I'm with you.
>
> The idea is like this.
<snip/>
Appreciated. Nice and clear.
> If Subversion had instead automatically sent every change or addition
> to the server as you made it, that wouldn't do anybody much good.
Agreed.
Perhaps I should see add as 'add-local'?
or add-working.
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.
The key point being to create, and work on the file in the 'working copy'
directory.
> > 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
OK. Makes sense.
>
> ...but I was talking about inside a working copy, which is probably
> the way you'll want to work most of the time.
Yes, but just starting out, I had n files on 3 machines that I want to get
into the repository to start.
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.
Sort of remote add and commit all in one?
Is there a move that I can use to take it from /path/file.ext to my
working directory?
That seemed to fail nicely.
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.
Agreed.
>
>
> > 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....
Yes....
Is there a way that I can see that file foo has been added to the
working directory, but not committed (yet), sort of a confidence booster?
>
>
> > 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.
Simply because this is my first foray into svn :-)
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.
Easy once this is understood.
>
> 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.
Wish that was in the book, big letters, *read this glossary first*
>
> > 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
The book basically says *don't* copy files directly into the working
directory IIRC?
yes
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-3-sect-5.2
<quote>you shouldn't change the structure of your working copy without
letting Subversion know what you're doing. Use the svn copy, svn
delete, and svn move commands to change the structure of your working
copy, and use the svn add command to place new files and directories
under version control.</quote>
What it doesn't say, is that the svn add *follows* altering the structure of
the working copy? E.g. copy a file into the working copy?
> 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 guess my point was that if FSFS is default, why mention BDB in the install
docs (except for updates perhaps)?
>
>
> > 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.
<grin/> seems to be, so far!
>
>
> > 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.
No, server is 'remote' (via http)
>
> If you're using the svn:// protocol, then there's an access file you
> can set up with usernames and passwords.
Tried that, I guess my net wasn't set upcorrectly, I couldn't get through.
Boy this tool is a bit flexible Ryan :-)
> 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.)
I thought I had that set up (as per the book).
I'm unsure since svn s kinda helpful, and remembers my password
on the local machine.
Thanks again Ryan.
I'm getting there
(surprisingly quickly all things considered).
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 6 21:36:36 2005