On Wednesday 30 November 2005 04:55 pm, Ryan Schmidt wrote:
> 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.
Again, that's part of the problem -- running 2 systems separately is not
affordable. Which leaves me back to editing code directly on the production
system. Since most code interacts directly with MySQL, and since I've got
all the memory I can afford for now, I can't run 2 instances of MySQL on the
system (and, if I did, it'd be a true pain to keep separate the different
ports for communication for test programs and live programs). I've got one
computer with the equipment needed for the system. To NOT edit live code
would mean setting up a sister system, since any programs, even if in
different directories, would still act on the same data and settings and
still interact with the same database.
I had a point, for a couple months, where I had an old server still running
and I was working on the new one. I could only run certain tests on the new
one for 2 (or fewer) days a week because the old server, which was still in
production, needed all the resources. It was an exhausting cycle of write,
predict, be ready, then 1 or 2 days of testing all day and most of the night,
so I could bust my butt for the next 5-6 days preparing for the next test --
knowing full well that if some parts weren't ready, it'd be a week before I
could test them again. I had to keep switching settings, phone lines, data
updates, and other things and it basically exhausted me. I went through days
where I had to have friends drive me to meetings or for errands because I was
no longer alert enough to drive safely.
If, and that is a big *IF*, I had know about Subversion, or even understood
the concept of any kind of versioning programming a few years ago, when this
started, I could have designed around it, and you have some good points,
which I really wish I could do. At this point, I've been on this for almost 4
years of programming, and expect to finish in 6 months.
I've got a great track record for not needing bug fixes. (For example, the
first version of the program that ran on my earlier server was written in a
hurry, so it could gather data while I did the programming, and I intended to
replace it later, after I knew what I was doing. It was my first program in
Perl, and a revision of the first program I had written after not touching a
line of code in over a decade. Once I got it up, it took 2-3 cycles to make
sure it was working right, and it ran perfectly, until I replaced it with a
program including multiple redundancies and error checking over a year later.
When I first learned Java, it was to write the program that my clients run on
their computers. I had never written a program for someone else to run
before. the first version I wrote has been online, in daily use by my
clients, for over 1 1/2 years. We found 4-5 bugs within the first 2 weeks,
and one since then.)
Since I expect to be done in about 6 months, and am exhausted, I am not making
any major changes in the setup at this point. When I'm done programming, a
friend who is helping me (unpaid) and I can add a number of clients who are
waiting for me now. Then I can hire a programmer, build a ghost system, and
let him use Subversion and solve this (and a few other issues) for me. I
know this sounds really PHB-like, but now that the new server is working, my
main purpose for version control is on the revisions of the client program --
however, I figured including the server with that, so I can track which
revisions on the server work with which revisions on the client program,
would make life easier.
> > 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.
I also got another reply, with a link to an example of backing up your /etc
directory, so you can easily update, commit, or checkout only what you need.
I know the terms are different, but the effect is close to the same. At this
point, I'm wondering if Subversion is really necessary to my server software
and if I wouldn't find it easier to use it only for the client program. I am
able to have a working and test copy of the client program and keep those
separate rather easily.
> 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.
Yes, you are right. Which is why I tested the hell out of this before it went
live. I work on a weekly cycle (used to be a 1-2 day cycle for data
gathering and sending it to clients), so, toward the end of testing, I was
able to run what amounted to a 1 week cycle in a day, so I could simulate 2
weeks of data gathering in the 2 days I had to test it. I made sure it was
all well behaved before I switched to the new system -- and then had the
indescribable pleasure of having to patch the code in real time for the 6-8
bugs that showed up after that.
> > 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.
Interesting. One issue I had early on was a similar mix of code and data. It
drove me nuts until I decided that certain things, like ANY images, went in
the images directory. There could be subdirectories, but they HAD to go in
there, so I didn't go batty trying to track all files of one type down. It
really helped my sanity -- but I'm also NOT working on a system spread out
over a number of computers. It's just on my server (originally, I had to
develop the database on one and the program on another, so, for a while, it
spanned 2 systems, but I hated that -- if the database went down, the server
was left SOL).
> 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.
I'm sure if I were going to continue, it would be worth it. The long and
short is that in June of 2001 I lost my job, there was no job market for my
field here, so I jumped in to start a business. The nature of the business
changed a few times, and when a lawyer/friend told me he needed certain data,
even though I hadn't programmed in years, I jumped on it. I am a writer,
first, last, and always. (I even came damned close to selling to Star Trek
at one point.) My goal is to finish this data gathering system, which is
sold on a monthly subscription basis, and use the income to give me time to
write, THEN to be able to pay for the equipment, cast, and crew to make my
own movies. I'm going this far off topic to make a point: I've been on this
program since Feb of 2002, when the chance came up. I had to work 16 hours a
day for a long stretch just to get to the point where I could stop charging
my life on credit cards. I'm tired of this, and I'm eager to finish my part
so I can focus on adding more clients, increasing the income, and hiring
someone who has been trained to do what I've had to do for the past 4 years.
I have a few standing rules: use FOSS whenever possible, write solid code and
get it done right instead of meeting a deadline with thousands of bugs, and a
few other odds and ends. Otherwise, when I hire a trained programmer, I'll
let him or her make changes that work. Until then, I just want to finish it
without making a mess.
> 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. :-)
It's the change tracking that I think will help -- and being able to roll back
to the same version of software a customer has. (Although one thing I've
created is an auto-updating system. I track MD5 sums of all files on a
clients system when logs are sent back, and any time a file is outdated, an
up to date version will be sent out automatically.)
> > 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.
I'm glad to hear I'm not the only one who avoids an IDE. I use Kate, part of
KDE on Linux. It's a text editor, with the files it has loaded listed on the
left, and a console at the bottom, so I have the editor and a term to test it
in all together in one window. Whenever I've tried to add more, I find I'm
too busy thinking about the tools than the work.
Hal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 1 01:57:06 2005