On Sat, Jan 22, 2005 at 09:44:42PM -0500, Carole E Mah wrote:
> 1.) How do I check out just *one file* from the repository? I don't
> want the entire directory structure, I just want one file.
It is not possible to check out a single file. The finest level of
checkouts you can do is directory level. You may export single files by
using 'svn cat' but then it's no longer a working copy.
> 2.) Even more important than being able to check out just one file,
> I'd like to be able to say something like, "check out only
> myPath/phpScripts/ and myPath/includes, but not myPath/images. Can I
> do that with one or two commands instead of having to issue dozens of
> little 'single file checkout' commands? I.e. can I use a wildcard in
> whatever the command might be that answers question number one above?
> Or can I say something like 'svn checkout
> file:///srv/projects/svn/myProject/myPath/*.php?
You can use checkout to checkout named directories, with and without
subdirectories. The manual describes this at:
<http://svnbook.red-bean.com/en/1.1/re04.html>
> 3.) Right now we just use RCS to manage versioning (no CVS, just
> RCS). Our normal working model is that all the files for project
> 'someProject' live in one place, /www/htdocs/projects/someProject/
> (inside the web hierarchy on the development machine), and everyone
> just edits the files in-place there...
The concept you're describing is normally referred to as a shared
working copy. And is generally considered to be less than optimal.
> Under the Subversion version control model, it looks like only one of
> person will be able to work on the working copy of someProject/ in
> the web hierarchy, and everyone else will have to check out working
> copies to somewhere else, e.g. their home directories, or even to
> their desktop Macs and PCs. I don't quite see how those people who
> are unlucky enough to have their working copies outside the web
> hierarchy will be able to "see" if the changes they made to the code
> are "working" properly. For one thing, the paths will be all wrong,
> since their working copy will be somewhere else in the unix file
> structure (and maybe not even in a web directory), or on a local
> desktop machine.
I would suggest you make a local configuration file to tell your
application the paths it needs and then not put this under version
control. And then have your developers checkout whatever part of the
repository they need to do their work and view the changes. A good thing
about not having a shared working copy is that you know that whatever
just broke the application is your own fault. Also you are more free to
do crazy things when you know that whatever you're doing does not affect
anyone else, let alone the live site.
> And more gallingly, every time we want to incorporate everyone's
> changes into the working copy in the web hierarchy, the person editing
> inside the working copy in the web hierarchy will have ask everyone to
> do a 'commit' and then he will have to do an 'update'. People won't
> be able to have their changes go live without going through the person
> designated as the master of the working copy in the web hierarchy.
Actually you could skip the idea of any one person owning the working
copy on the live site and make it possible for everybody to update. This
could be done through sudo f.ex. This would lead to the advantage that
you are sure only things that are actually commited to Subversion will
end up on your site. I don't understand how you today can manage a live
site where people are editing the files on top of each other. Aren't you
having problems with people editing files on top of eachother? And the
site being unavailable due to programming work being done on the files?
> 4.) Must I *really* use this whole 'trunk/branches/tags' directory
> structure?
No, Subversion imposes no arbitrary limits to the way you choose to
structure your repository.
> I hate it, because then after I check out a working copy to
> my web hierarchy, my documents now have 'trunk' in the URL path, which
> is just nuts.
Not necessarily. As I already described you can check out named
directories f.ex. trunk. Alternatively you could alter the webroot to be
$PATH_TO_WC/trunk instead of just $PATH_TO_WC.
> I mean, I can move them out (i.e. up one directory), and
> then delete the 'trunk' dir, but then what happens when I try to
> 'commit' the files back to the repository? Will it mess up because I
> changed the directory structure? Can't I just dispense with 'trunk/'
> and 'branches/' and 'tags/' altogether? Or are they so terribly
> important that I must keep them around?
That depends on the project you keep in Subversion. With Subversion you
can start out without and if you later on decide to start using them
it's trivial to restructure your directory while keeping history.
I hope this has made the world of Subversion a little less confusing for
you.
--
Cheers,
- Jacob Atzen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jan 23 12:11:57 2005