Hi Carole. I'm in a similar situation, in the process of converting our
company's development strategy from an
everybody-just-edits-on-the-web-server-and-breaks-stuff-for-other-
people-all-the-time model to an
everyone-has-a-working-copy-and-can-do-what-they-want-and-commit-when-
they're-done model. Before I answer your questions, I'll describe how
we're going to do it, which may help you to see how (I think)
Subversion is supposed to be used, and help you see where you'll need
to adjust your working habits and preconceptions to match.
We have, as you do, our project directory on a central web and file
server. For example, we have a project in /data/vhosts/project1, and we
set up an Apache vhost pointing, say, http://project1.example.com/ at
/data/vhosts/project1/htdocs. /data is a RAID 5 array with lots of
space. Everybody edits files on their Macs or PCs by accessing the
project's directory over SMB. People sometimes step on each other's
toes, sometimes editing the same files, or sometimes breaking parts of
the project while they're in the middle of developing a more-complex
feature. It's not a good situation.
To fix this, we'll set up a Subversion repository at /data/svn and it
will contain the projects and their trunk, branches and tags
directories as recommended, because, after reading the documentation, I
agree that this will be helpful. Our repository will look like this:
/data/svn <-- root of the repository
/project1
/trunk
/htdocs
[more directories]
/branches
[the branches]
/tags
[the tags]
/project2
[and so on]
/data/vhosts will no longer be exported as an SMB share. Users will not
change files there directly. Instead, users will check out a working
copy of project1/trunk. Since our client workstations are not set up to
be web servers (and we don't want them to be), users will check out
their working copies to the web directory in their home directory on
the web and file (and now Subversion) server. For example, I might
check out project1/trunk to /home/rschmidt/public_html/project1. I can
mount my home directory's SMB share on my workstation and edit files in
my GUI editor as usual, and hopefully I can find a reasonable GUI
Subversion client to handle moves, renames, adds, deletes, and such. I
understand TortoiseSVN is quite good on PCs, but I haven't found the
right one for Mac yet. SvnX seems to be the only option, but I got
confused the first time I tried to use it. But that was before I read
the Subversion book so maybe it'll make more sense now.
Users can check that the changes they're making are working by
accessing their own private web version of the project, at, for
example, http://server.example.com/~rschmidt/project1/htdocs (or we may
add some Apache directives so that having "htdocs" in the URL is not
necessary). When users are done developing the feature or fixing the
bug they're working on and everything works in their private web space,
they commit the changes to the repository.
At this point a post-commit hook will run on the server and do a
checkout of project1/trunk to /data/vhosts/project1, so that the
customary http://project1.example.com/ URL always reflects the current
development version of the project, and people like my project manager
or my boss, who don't want to have to know how to use Subversion, won't
have to, and things will work for them like they always have.
Now to answer some of your questions:
On 23.01.2005, at 03:44, 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.
>
> Why? You might ask. Because I just want to check out and work on ONE
> damn file, for example, index.php. I don't want to wait four, five, or
> more minutes for subversion to slowly check out the entire working
> copy, which includes many, many megabytes (and eventually gigabytes as
> I add more files) of stuff including image files (for which there will
> be no room on our unix machine if the several people working on the
> project all have to check out an entire 'working copy' each).
> 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?
As has been said, you cannot check out a single file. You can export a
single file, but then it's not a working copy, and therefore can't be
checked back in if you make changes. Subversion stores information in
the .svn directory, and if you don't check out a whole directory, there
would be no parent directory in which Subversion could create its .svn
directory.
In our projects it's also very common that fixing a bug or adding a
feature requires changing many different files, and these should all be
committed at once, so all the files need to be in the working copy at
once. And probably, many more files, possibly the entire project, will
be needed in the working copy for the working copy to function properly
when viewed in a browser using the user's private web URL.
Given my introductory description of what I hope will prove to be a
reasonable way to work on web site projects with Subversion, I
recommend you check out all of trunk. You only need to do this once.
From then on you can keep your working copy up-to-date by periodically
using the svn update command to resynchronize it with the current
development version. If you have concerns of disk space, then you might
want to invest in additional hard drives. :-) They shouldn't be that
expensive. Get yourself 3 or 4 250-GB drives and a hardware RAID card
and you should be all set. With RAID 5, you even get speed benefits,
and protection if a disk fails.
> 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, with emacs or vi or pico (after
> ssh-ing into the unix machine), and some of us work remotely in BBEdit
> and save to the server every ten minutes (BBEdit keeps open an SFTP
> connection to the unix server).
>
> 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.
So, you see, nobody should be working directly in the Apache document
root anymore. Everybody should work in their own working copies.
> 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.
I think that checking out the project to a directory inside the user's
web space should be sufficient for this.
> 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.
This, and the desire not to have to teach all our programmers how to be
Apache administrators, is the reason why we decided not to check out to
local machines but instead to check out to the home directory on the
server. As to the paths, you'll have to program your project so that it
works regardless what directory it's in, using relative filesystem
paths when accessing libraries or include files, and using absolute
paths when dealing with things like a document upload directory, which
you probably won't want to duplicate on a per-user basis.
> 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.
> This is all just so confusing that I'm starting to think we should
> just keep using RCS.
As I hope you see, having everybody editing in their own working
copies, and having a post-commit hook do a checkout to the directory
behind the "primary" development web site's URL whenever changes are
made, should make this all "just work."
> 4.) Must I *really* use this whole 'trunk/branches/tags' directory
> structure? 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.
First, no. You do not need to use trunk, branches, and tags, or any
other naming structure. Subversion attaches no meaning to these
folders. They only have meaning if you mentally assign one to them.
It sounds like you're doing something wrong, though. You say that after
a checkout your documents have "trunk" in the URL. It sounds like,
using my example heirarchy above, you're doing a checkout of project1
instead of a checkout of project1/trunk. In other words, you're getting
a working copy which contains the current development version (trunk),
plus all branches, plus all tags. That's not a particularly useful way
to work, I think. You'll more likely want to check out project1/trunk,
since you're most likely to be working on the current development
version.
We're going to use branches and tags as described in The Book, because
we have the situation that we develop a web site, and when development
is finished, it goes to the live server. Of course, no web site is ever
"finished"; the client always wants "just one more change," or later
some big change. So when we are ready to deploy to the live server, we
will create a branch of trunk and call it, say, branches-1.0. We'll
test branches-1.0 for awhile, and if we find problems, we'll fix them
in branches-1.0 and also in trunk (using Subversion's merging features
to propagate the change in a not-entirely-manual way). Once
branches-1.0 works to our and our client's satisfaction, we'll copy
branches-1.0 to tags-1.0.0. Then, on the live server, we'll do a
checkout of tags-1.0.0, and version 1.0.0 of the site will be live.
Development of new big features continues to take place (even during
testing and bug fixing of branches-1.0) on trunk. When the client sends
the inevitable bug report against 1.0.0, we'll fix the problems in
branches-1.0 and also in trunk, and after sufficient testing of
branches-1.0 to confirm that the bug is squashed, we'll create
tags-1.0.1 and check that out on the live server, and 1.0.1 will be
live. And when one day the new features in trunk are ready to be
deployed, we'll make branches-1.1, and so on.
> Thanks for any insight on any of my admittedly naive questions.
I hope I've been able to help. It's taken me awhile to wrap my head
around the concepts too, and I'm still not done reading The Book, but I
think, slowly, I'm getting it, and it's going to be good for our
company, and I hope it will be for yours too.
\r
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jan 23 18:18:01 2005