You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dave Pawson <da...@gmail.com> on 2005/09/06 12:57:44 UTC
Problems adding new files. New user
Setup.
svn server setup on Fedora+Apache
No problem.
Initial data import worked as expected.
Using 1.2.0 client on Windows.
checked out data no problem.
I want to add a number of files to the 'working directory'
svn help add says
usage: add PATH...
When I try
>svn add /path/to/file
I get
svn: '..\tmp\trunk' is not a working copy
How do I add a 'new' file to my working copy to upload to the server please?
'the book' isn't much more help.
svn add foo
Schedule file, directory, or symbolic link foo to be added to the
repository.
Any help appreciated.
regards
--
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
Re: Problems adding new files. New user
Posted by Dave Pawson <da...@gmail.com>.
Thanks for the explanations Ryan.
I just hope others learn from it too!
On 06/09/05, Ryan Schmidt <su...@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
Re: Problems adding new files. New user
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
Re: Problems adding new files. New user
Posted by Dave Pawson <da...@gmail.com>.
On 06/09/05, Ryan Schmidt <su...@ryandesign.com> wrote:
> Sorry if I wasn't clear earlier, but yes, what you've described above
> is exactly how you do things in Subversion.
Great. Interesting that I didn't get that from the 'book',
rather, from a Google search.
>
> You said you imported your project successfully. That means you
> already used "svnadmin create" to create a repository, and you had a
> directory which contained your project, and you used "svn import" to
> put it into the repository.
Yep. But that was on the server (FC4)
>
> To continue working, you should now have deleted the local directory
> that you imported, and created a new working copy of what's in the
> repository by using "svn checkout".
No... but I will do (now :-)
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?
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?
>
> 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?
>and I had no background in
> version control.
Ditto. Failed miserably to use CVS.
If you see any specific parts of the book that could
> have been clearer to enhance your understanding, please tell; I think
> the author is always looking for constructive criticism.
As an author, I'm aware of (and reluctant to give feedback) on other
peoples work.
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?
My crude view is,
move files into 'working directory' (no glossary to define this
overloaded definition?)
do an add
do a commit
that 'adds' them to the repo?
More to the point.
I installed svn on apache (the ... webdav thingy was easy, but I
missed it first time)
no problem.
The client side on Windows was easy... except I'd used the cygwin before, so
adding the single dll (why can't it be included inthe download?) was easy.
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?
Enough.
I wanted to sync n machines with one set of files.
subversion seems as if it will work out well for my needs.
either way, thanks for the tips Ryan.
btw
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?
(Python i/f next :-)
regards
--
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
Re: Problems adding new files. New user
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 6, 2005, at 16:49, Dave Pawson wrote:
> Sorry Ryan. I'm either not following you or it isn't making sense.
>
> [snip]
>
> I tried another tack which *seems* to work.
>
> I have a 'working copy' (directory created when I checked out the
> files)
> directory (contains tags, trunk and branches)
> cd to that directory
>
>> cd <wkingDir>
>
> copy any old file into the trunk directory.
>
>> copy /temp/trash.txt /trunk
>
>> svn st
>
> shows me that svn has a foreigner on board ;-)
> ? trunk/trash.txt
>
>> svn add trunk/trash.txt
>
> Now commit
>
>> commit -m "test file, trash.txt"
>
> this seems to work OK, and makes sense to me (OK OK :-)
>
> Is that a reasonable way of introducing new files?
Sorry if I wasn't clear earlier, but yes, what you've described above
is exactly how you do things in Subversion.
You said you imported your project successfully. That means you
already used "svnadmin create" to create a repository, and you had a
directory which contained your project, and you used "svn import" to
put it into the repository.
To continue working, you should now have deleted the local directory
that you imported, and created a new working copy of what's in the
repository by using "svn checkout". 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) 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.
I'm surprised you had trouble after reading the book.... It was all
fairly clear to me after I read it, and I had no background in
version control. If you see any specific parts of the book that could
have been clearer to enhance your understanding, please tell; I think
the author is always looking for constructive criticism.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems adding new files. New user
Posted by Dave Pawson <da...@gmail.com>.
On 06/09/05, Ryan Schmidt <su...@ryandesign.com> wrote:
> > When I try
> >
> >> svn add /path/to/file
> >
> > I get
> > svn: '..\tmp\trunk' is not a working copy
>
> /path/to/file is within \tmp\trunk, yes?
no. Must the two be related?
should I cd to a specific place first?
Not stated (as I read the books :-)
>
> Could you show us the commands you used to create \tmp\trunk? I
> presume you intended for \tmp\trunk to be a working copy, but
> Subversion doesn't think it is for some reason, so let's find out why.
Its just a file on my filesystem. Nothing special about it.
>
> It should just be as simple as (Unix syntax; sorry, you'll have to
> convert mentally to Windows)...
No probs. I need to do this on FC4 too!
>
> cd /tmp
> svn checkout url://to/repository/project/trunk # check out a new
> working copy
... sort of a a working copy of nothing?
or do you mean a working copy of all the files in trunk directory
of 'project' ?
> cd trunk # go into the new working copy
I *think* you mean a working copy of an empty directory in the repo?
> touch new-file # make a new file
> svn add new-file # add the new file to version control
> svn commit -m "Adding new-file" # check in the new file
Sorry Ryan. I'm either not following you or it isn't making sense.
Your line seems to follow
http://www.developer.com/tech/article.php/3503151
I tried another tack which *seems* to work.
I have a 'working copy' (directory created when I checked out the files)
directory (contains tags, trunk and branches)
cd to that directory
>cd <wkingDir>
copy any old file into the trunk directory.
> copy /temp/trash.txt /trunk
>svn st
shows me that svn has a foreigner on board ;-)
? trunk/trash.txt
>svn add trunk/trash.txt
Now commit
>commit -m "test file, trash.txt"
this seems to work OK, and makes sense to me (OK OK :-)
Is that a reasonable way of introducing new files?
TIA
--
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
Re: Problems adding new files. New user
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 6, 2005, at 14:57, Dave Pawson wrote:
> [snip]
>
> Initial data import worked as expected.
>
> [snip]
>
> checked out data no problem.
>
> [snip]
>
> When I try
>
>> svn add /path/to/file
>
> I get
> svn: '..\tmp\trunk' is not a working copy
/path/to/file is within \tmp\trunk, yes?
Could you show us the commands you used to create \tmp\trunk? I
presume you intended for \tmp\trunk to be a working copy, but
Subversion doesn't think it is for some reason, so let's find out why.
It should just be as simple as (Unix syntax; sorry, you'll have to
convert mentally to Windows)...
cd /tmp
svn checkout url://to/repository/project/trunk # check out a new
working copy
cd trunk # go into the new working copy
touch new-file # make a new file
svn add new-file # add the new file to version control
svn commit -m "Adding new-file" # check in the new file
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org