image uploads and version control?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I'm developing a php website that I have under subversion version
control. I'm working on an image upload functionality, and in the
middle of it I realized that any files that a user uploads will not be
under version control, and if I checkout or export the site from
version control, and deploy it, it won't bring any of the uploaded
files with it.

I'm looking at php subversion functions, but the manual says that
they're experimental, and my webhost hasn't deployed them.

What's a workaround for this? I'm thinking that I'll have to have a
parallel site for image hosting. For example, I'll have, hosted under a separate filesystem directory, and
then in the actual website that a user would peruse, any img src would
reference . When I accept my uploads, I'll do my
filesystem copy to the images filesystem link.


Re: image uploads and version control?

Quoted text here. Click to load it

Well, here's the problem, as I perceive it:

Say my website is served from a directory called /home/user/website .

Users of the website need to be able to upload images, which in the
current incarnation of the website I specified to be served /home/user/
website/images. This directory currently holds all images served with
the site, not just user uploaded images.

My 'packaging and distribution' practice currently consists of 'svn
export http://svn-host/website/trunk', and then linking that to the
website directory, e.g. 'ln -s website-trunk-revision-189 /home/user/

So the problem is, unless user uploaded images were put under version
control, which I would have to do by migrating the image from the live
to the development site, and then putting it under version control,
the user uploaded images wouldn't be in an exported revision of the

So my thought would be rather than try to include them in version
control, move the functionality of accepting and serving user uploaded
images from a subdirectory of the website to its own domain, and just
not keep it under version control.

So when I export the website, it won't include any uploaded files,
unless they were put under version control.

Re: image uploads and version control?

Quoted text here. Click to load it

Well, I can do all that in one fell swoop by creating a symbolic link.
I don't have to worry about whether or not I've deleted anything in
version control that I then need to remove in the production; it's
already done for me. If I had to delete files what were already
deleted in version control, then in my mind, I'm doing manual labor
that the computer should be doing anyway.

Also, by using symbolic links, I can deploy, test, and fallback to the
old directory by re-linking very easily if I need to.

Finally, by using an adequately named directory to symlink to, I know
what version I have deployed as production. If /home/user/website/
production is a symlink to /home/user/website/trunk-R255, then there's
a pretty good chance that it's revision 255 that is currently in
production. If I were just copying files into the website directory, I
would have to have another way to know or guess what revision was
actually deployed. I could reconcile my svn history against my bash
history, and try to extraploate what version is currently deployed,
but that takes some leg works and concluding. Of course, both ways are
subject to failure if you don't practice your procedures properly, but
I think symlinking is harder to screw up.

So, three good reasons to use svn exports in and symbolic linking to
deploy a website.

Quoted text here. Click to load it

Well, I didn't *intentionally* make it to complex; my assumptions
about website design and structure sort of led me to the place that
I'm in now.  :)

I'm making a dymanimc website where users can input data. The source
code of the website is under version control, and the user-generated
data is stored in MySQL. So far, so good. If I needed to re-generate
the website for any reason ( backup, new webhost, errant rm -rf ), all
I needed was a recent export from subversion and the latest MySQL

So now I think I'm beginning to understand the philosophy. In the
past, I could get away with keeping all the website images under /
images, or some similar structure. But now that I'm accepting user
data that I can't or shouldn't put into MySQL, I need to find a third
place to store things. I liked the simplicity of having the whole
website existing as svn export + mysqldump, so I was hoping there was
a way I could keep this new kind of data within that system. But I
can't. Now, the website must be mysqldump + svn + some other thing.

Re: image uploads and version control?

Quoted text here. Click to load it

I suppose there are tools for this. Care to give me a sales pitch on
any of them? Right now an svn export does everything I want, with no
risks of the downsides of copying or synchronizing.
And the deployment tool is built right into the version control
system. Why do I need an extra tool here?

Quoted text here. Click to load it

That would always work if the development and production environments
were identical, but in my experience, they're not. Code that passes a
test in the development environment might still have problems when you
roll it out in production. And then that happens, you'll want to roll
it back *really really badly*. :)

The situation I've been involved in before was where we made a change
to the database structure in development which we didn't replicate in
the production database. The code was developed and tested in
production against a new table structure, and it passed all its test.
Then when we went to roll it out, SQL errors all over the place. It
was quite a relief to be able to roll back the website with a simple
command. ( BTW, I'd really like a smart version control system for our
table structure, one that could do ALTER TABLEs appropriately when

In our situation, we have a development server, and a production
server with a staging hostname and a production hostname. Once a
feature pasts testing on development, it goes out to staging. Staging
is on the production server and connects to the production database.
We do 'pre-live' testing there.

The great part about this is the seamless deployment from stating to
production. Our initial svn export gets linked to the staging
hostname. E.g.:
$> ls
  website-release-320 -> website-release-320/ -> website-release-320/
$> svn export http://svn-host/website/releases/release-345 ./website-
$> rm -rf; ln -s ./website-release-345
$> ls
  website-release-345 -> website-release-345/ -> website-release-320/

Where was previously linked to ./website-
release-320 . Now the new code really is in the production
environment. There shouldn't be any problem in production that
wouldn't be apparent here. So, after we've done the testing at
staging, we do:

$> rm -rf; ln -s website-release-320
$> ls
  website-release-345 -> website-release-345/ -> website-release-345/

The deployment of the new code to live takes milliseconds.

We can let the 320 revision hang around for a while; it's not being
served, and it's a "known good configuration" of the website
( provided it doesn't reference any outdated database structures :)
that we can rollback to if needed.

Quoted text here. Click to load it

That's a good idea. We're suing subversion, which doesn't have tags,
but the manual says you get the same functionality by doing a release

Knowing myself and my computing habits, I wouldn't like to assume that
a directory is the latest tagged released; it may not be. ( My most
difficult bash-head-against-wall troubleshooting cases are always
faulty assumptions ). By creating a directory named trunk-R273 or
release-R503, then there's a greater likelihood that that directory
actually *contains* revision 503. Not that there's anything magical in
naming it as such, but hopefully when I'm improperly naming a
directory ( e.g. svn export http://svn-host/releases/R502 ./website-
release-R498 ), the cognitive dissonance becomes apparent, and I stop
and say "Hey, what am I doing? This is *wrong*!" For me at least,
there's a lesser likelihood of that happening when I'm doing export to
the generic directory name that we've been using for years.

Re: image uploads and version control?

Quoted text here. Click to load it

Well, I guess I don't know how others roll out websites from
subversion, but I'm just using 'export', and then creating a symlink
of the svn export to the webhost directory. So the problem is, if I'm
serving user-uploaded images out of a subdirectory in the website
( e.g. /user/home/website/user-uploaded-images ), unless new uploads
are put under version control, they would not exist in an export when
I roll out a new release of the website. So I guess if you want to
call that 'backup' functionality, I see that side of it, but to me, it
isn't any different than just making sure all the pieces of your
project exist when you do an export, which I think might be an
implicit functionality of version control.

When I use svn export to roll out a new version of the site, I could
copy the user uploaded images into the image directory, but that adds
an extra step to releasing a new site, and I like to keep things
simple. I have enough to worry about when I roll out a new version. So
my thought now for user uploaded images is simply not to serve them
from within the web directory, but put up a whole other host that's
not under version control, and serve them from there.

Re: image uploads and version control?

Quoted text here. Click to load it

I'm using subversion for version control. If my website has an image
that's part of the website, it goes under version control, like any
other file that's part of the website. When I say it belongs under
version control, I mean that "Version 3.x has X version of this logo,
Version 4.x has another version".

If versioning images and other binary files are not the purview of
version control, then why does subversion have functionality for
versioning binary images, such as locking, etc.?

I'm not using it for 'backup' in the sense of "Oops! I deleted this
file accidentally. I need it to get it back, so let me go into the
backup and retrieve a copy of it. What is the definition of "backup"
that you're using here?

I don't see how this is a backup issue rather than a version control
issue. I think you might argure the point that this might be a
packaging and distribution issue as Charles Calvert did earlier, but
in this case, it isn't a c++ solution that requires a build
environment -- here, "svn export" *is* the packaging and distribution.
If you're using php and svn, what extra packaging and distribution
would you need for a site that's not released to anybody else, or
installed on any other systems?

Site Timeline