Hal Vaughan wrote:
> I'm not sure if I fully understand the related issues, but in
> response to an earlier problem, I got this suggestion from David Gale:
>> There're instructions in the FAQ
>> (http://subversion.tigris.org/faq.html#in-place-import) on how to do
>> an 'in-place' import, such that the source becomes a working copy.
>> Works very smoothly, in my experience. I've used it several times,
>> and will probably continue to use it instead of import for any
>> future projects I need to set up.
> The example in the link is how to keep the files in the /etc
> directory in Subversion without having to checkout the entire
> I've looked at this and have a few questions. If I understand it
> correctly, this would be what I'm looking for. I have to work on the
> live files used in production. (I *really* don't want to get in
> another discussion about this -- almost all my programs interact
> directly with the database, files, or equipment working on the main
> server, and as a small business with one person, I can't afford a
> duplicate development system.) I can't keep creating extra
> directories to make working copies. I want to be able to track my
> files in the live directories by updating one when it's been changed
> or checking out only the file that I modified. Of course, if needed,
> I'd like to be able to roll back an entire directory or directory
> The section in the FAQ that the link goes to sounds like it'll work
> for me, but the example is not clear to me. So I have a few
> 1) The only reference to a term for this is in the link. Is it
> called an "In Place Import"? If not, what is the term for this?
> 2) Can I use this to check files in and out from the system I'm
> working on, if I can't create or move directories around?
> 3) Will Subversion, each time I check a file in, register that as a
> new version overall, so it'll see that as a new version, the same as
> if I used it regularly?
> I'm having trouble understanding some of the ways Subversion works,
> and I'm not completely clear about this topic, but it looks like it
> would help me.
> Thanks for any help in understanding this!
I'm not sure I understand your questions, since they don't directly apply to this process. Let me try to explain.
Your original question was along the lines of how to import files into subversion, and have the source of the import become a working copy. 'svn import' doesn't do this, as it leaves the original files alone; after the import, you need to checkout a brand new working copy. Because of how subversion works, however, you can checkout an empty directory into the current directory (turning the current directory into a working copy), add the existing files, and commit them--effectively importing the files and creating a working copy, just like you'd requested.
An example: You've been working in /some/project, and now want to put that code under subversion, specifically in svn://example.com/proj, without having to delete & recreate /some/project itself. So:
$ cd /some/project
$ ls -a
. .. bar.h foo.c
$ svn mkdir svn://example.com/proj -m 'Preparing directory for import'
Committed revision 1.
$ svn co svn://example.com/proj .
Checked out revision 1.
$ ls -a
. .. bar.h foo.c .svn
$ svn stat
$ svn add *
$ svn ci -m 'Initial import'
Committed revision 2.
As to your questions: 1) There is no official term for this, since it's just a combination of svn checkout, svn add, and svn commit; unofficially, it's called an "in place import". I tend to quote it to try to prevent people from thinking that I mean something using svn import. 2) Not sure what you mean, here. Once you've done the checkin, you've got a working copy, so there's no need to do another checkout. But you can do this to turn your existing code into a working copy without moving it. 3) After doing this, subversion will continue to work as normal, simply because everything *is* normal. So, yes, every time you check in, it creates a new revision in the repository.
Does that help?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Dec 6 18:55:54 2005