On Nov 30, 2005, at 21:10, Hal Vaughan wrote:
>> Really not such a great idea to have your repository inside your
>> working copy. Working copies are supposed to be just that—copies
>> where you work. The fact that it's a copy (of what's in the
>> repository) is supposed to mean that you can freely delete the
>> working copy at any time, or create new ones for separate tasks. By
>> putting your repository inside your working copy you create a
>> dangerous confusion.
>
> Yeah, I figured it's not the greatest idea, but moving it involves
> changing
> settings on that machine and the systems (plural!) it backs up to.
Your original goal of keeping everything under /thresh/threshNet
remains met, so I had thought that, if your backup script(s) back up /
thresh/threshNet that they would thus not need to be modified.
> The other
> problem, and I can hear people scream in terror now, is that I'm a
> small
> business and can't afford more computers, so this is the computer
> the system
> actually runs on. I have to edit the code on the working,
> production model.
Having a single server doesn't need to be a problem. While we do have
two servers, one for development work and one for the production
site, we have a few more developers than you do, and the single
development server is happily accomodating 10 developers
simultaneously working on multiple working copies (which are all
stored on the same server and accessed via Samba shares). The
production server not only houses the production site, but also a
staging environment where we put new versions of code for customer
approval and a training environment where the customer can teach new
employees how to use the tool.
What I mean to say is that, while you needn't think about buying more
hardware, you should think about ways to make the existing hardware
work better for you. Editing the live code as a means of development
is just not a great plan, and I'm sure you realize that. Perhaps
you've already run into some problems as a result of this development
method. As a first step, I could suggest that you have two working
copies—one for your development work and one for the production site.
Configure the existing Apache vhost to point at the production
working copy and configure a new vhost pointing at the development
working copy. Then you can work in the development working copy,
making changes, adding new features, and checking your work on the
stage vhost, and when you're done, you can commit it to the
repository and then update the production working copy to push the
change live.
> The system needs certain databases, as well as expensive modems to
> work
> properly, as well as access to dial-in systems. I simply CANNOT
> afford one
> production system and one "working copy" system. I tried that for
> several
> months and the little things like swapping the phone lines,
> changing times
> when one was allowed online and one wasn't almost drove me insane.
> It was
> also almost impossible to keep them synced in terms of data and
> needed logs,
> since I could not use a scheduled backup like rsync, since it would
> often
> overwrite files I was working with.
One of the nice things Subversion gives you is that you don't have to
worry about what files you need to copy to get the site up-to-date.
If the site is in the repository, a simple "svn up" will update a
working copy to that state. Doesn't matter if your development occurs
in a second working copy right beside the production one or on your
home PC. As long as you've committed your changes to the repository,
"svn up" will know what to update. And should you ever split the
system into two servers, it's exactly as easy, assuming both machines
retain access to the same repository.
As to databases, our systems are also heavily database-based (over
1GB of data in over 300 tables, which seems large enough to me). On
the production server, we have separate databases for production,
stage and training, to keep those environments separate, but on the
development server, all 10 developers share a single development
database instance. If setting up a second database for development is
too cumbersome, and if critical changes in the database are rare, you
can probably get away with a single database for both working copies.
But obviously if you go and rename a field in the database as a part
of your development effort, then the production site will have
problems until you get that code change into the production environment.
> It's a small business, I get to finish code when I consider it
> finished (not
> on deadline), and do it my way, but I just don't have the funds and/
> or time
> to do everything the way some would want it done. I have a budget,
> and it
> has to pay for the computers and food and rent and heating... I'm
> also
> working 16-20 hours a day, so taking time to alter my setup for
> backups so I
> can do things Subversion's way is not something I relish doing.
>
> I'm not fighting you -- just pointing out there are many things
> that can limit
> our situations or setups.
Definitely. And of course you have to weigh the pros and cons and
decide for yourself. For us the biggest problem with our web sites
was the many places where files could be uploaded. If we had an image
database, then we likely had an htdocs directory, inside that an img
directory containing buttons and headers and other static site
graphics, and then a imagedb directory inside that with uploaded
images and their thumbnails, probably named with the ID of a
corresponding record in some database table. This haphazard mixing of
the system's code with its data has been the most difficult part of
switching to Subversion, but in our new projects, and in the old ones
that we've converted, we now keep all code in the working copy /
repository and keep all data which can be manipulated by the site in
directories completely outside the working copy. We've been using
Subversion for almost a year, and I'd say we're now fluent in and
quite comfortable with the system. Even our junior programmers are
flying through the TortoiseSVN menus, merging changes to a branch,
undoing changes with reverse-merges, making tags, and updating the
production systems by updating their working copies (basically). It's
taken some time, but for us it has been worth it. Just the fact that
multiple developers can work on multiple tasks without stepping on
each others' toes is the biggest relief for us (realizing that that's
not important for your situation). And the ability to track when a
change was made, and more importantly why, has already helped us
solve countless problems, not to mention prove to our customer that
yes, the reason that a change was made was that they did in fact ask
us to make it. :-)
> am self taught otherwise). I only recently learned what an IDE is,
> and am
> not using one because it's too damned hard to change everything in
> my setup,
> which works well for me, into what an IDE wants me to have.
If you have a system that works, by all means, keep it. I don't use
an IDE either; I get my famously with just a free programming text
editor. The Subversion GUIs I've found so far haven't seemed easy to
me either, so I've kept to the command line, which works for me,
which is what it's all about in the end. As to whether or not you
need a version control system like Subversion, only you can answer
that. But if you've recognized that you want to keep better track of
what you change, and make sure only good code goes to the production
system, Subversion is a great way to help get that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 30 23:02:45 2005