Using Subversion (svn) to manage website files?

[David]

[Apologies if you have seen this already: I didn't get any replies to
my post in more local groups, so re-posting to worldwide groups.
Apologies in particular if this is only tenuously on-topic in the
programming groups, more a question about a programming utility, rather
than about programming itself..]


I'm planning to use Subversion (svn) to manage and deploy website files
on our development and live websites, but am new to Subversion and so
would be very grateful for some advice..

We have a couple of separate websites which are hosted on the same
server, and to make it easier to maintain the development and live
versions of each, we want put our custom back-end PHP code into a
Subversion repository, so that we can make changes, then deploy the
code to the development server, and then once tested and working,
deploy to the live server.

We have been given access to a repository on our workplace Subversion
server. I am currently skimming through the Subversion book online,
and trying to get to grips with how it all works, and how to make use
of it.

Our two websites are each in separate folder trees on the server, and,
as well as our custom back-end code, also each include CMS files and
other content files which we do not want to get mixed up into or
affected by the repository.

"Site 2" was set up by myself and is structured as follows:

/data/webs/site2/ - the root of all site files
/data/webs/site2/php/ - code to put under version control
/data/webs/site2/site/ - DocumentRoot containing CMS files

The 'site' folder containing CMS files, etc, should be ignored by svn
and not touched by it in any way, with the possible exception of one
named subfolder (and its subfolders) which contains (because of the
way the CMS works) 'stub' PHP files which need to be in this place in
the file system, and in turn only include our 'real' PHP files. It's
not essential that we can manage these files (they'll be created once
as needed and then never(?!) changed, so can just be manually created
on both the development and live servers), but it would be "nice" to
be able to minimise repetition.


"Site 1" I inherited and has a less structured layout.. :-(
(and isn't documented well-enough to know how easily it would be to
change..)

/data/webs/site1/ - post-hoc attempt to make a tidy root for all site1 files

/data/webs/site1/[various] - various folders at this level, some of which
we should put into version control from now, some of which we might want
to put into version control later, some of which we might want to
permanently(?!) leave outwith version control.

/data/html/www/ - the unhelpfully-named location for the DocumentRoot
and CMS files for site1 (to be untouched by svn)

(/data/webs/site1/site is a symlink to /data/html/www/ in the forlorn
hope that everything can be moved under site1 eventually..)

/data/ also contained other folders for site1 cluttering up that
top-level. These have been moved into the corresponding locations under
/data/webs/site1/ with symlinks from /data/ in case of any hard-coded
paths hidden away that point to the original locations)


There are also other folders in /data/ unrelated to the websites, and
other folders for other (simple/stub) websites in /data/webs/ which we
don't want to put under version control.

Yes, I suspect that if I wanted to get _there_, I wouldn't start from
_here_, but we are where we are..


So... (after a very long introduction) what I am wondering is how best
to set up the file structure in our repository.

With there being two separate websites (possibly, but not imminently
likely, others to follow later), I'm wondering whether they can even all
co-exist in the same repository happily enough, or even whether I would
be better asking for a separate repository for each.

There's then the question of folder structure in the repository.

Can I (sort of) "mirror" the webserver layout from the /data folder
downwards, bearing in mind that there exist existing files on the server
that must not be included in the repository and, equally importantly,
must not be overwritten when the repository contents are checked out or
updated onto the respective webservers?

(This would possibly involve some horrible 'ignore' properties, assuming
I understand them properly and it would even be possible?)

From my experience of svn so far, it appears that it expects you to
create an empty folder where you then check out your working copy,
which seems to suggest against being able to check out a copy into
a folder containing existing files (which you do not want to overwrite).

Is my only option then to only start the file structure from the
top-most folder that will be under version control? (So that the files
that should not be tampered with are 'above' this level and so are
safely out of the way?)

(eg, svn would contain a folder 'php' corresponding to /data/webs/site2/php
for site2, and [various] folders for the [various] "roots" for site1.
If site1 had been following "the rules" then its code files would also
have been in a corresponding 'php' folder, but this wouldn't be a
unique name at this level, implying the need for site1/php and site2/php
in the repository (but would that cause the problem that the other
unmanaged files/folders on the webservers under site1 and site2 wouldn't
be "safe" from over-writing?))


Thanks for any advice,


David.

[crankypuss]

On 05/13/2013 03:51 AM, David wrote:
> [Apologies if you have seen this already: I didn't get any replies to
> my post in more local groups, so re-posting to worldwide groups.
> Apologies in particular if this is only tenuously on-topic in the
> programming groups, more a question about a programming utility, rather
> than about programming itself..]

Suggest that if you don't get the help you need here, you try posting to
alt.www.webmaster and/or alt.comp.lang.php since most of the folks who
frequent those groups are involved in website development using php.

[Rainer Weikusat]

David <da...@55952163-3189045.bogus.domain.invalid> writes:

[...]

> I'm planning to use Subversion (svn) to manage and deploy website files
> on our development and live websites, but am new to Subversion and so
> would be very grateful for some advice..

[see original for details]

> So... (after a very long introduction) what I am wondering is how best
> to set up the file structure in our repository.
>
> With there being two separate websites (possibly, but not imminently
> likely, others to follow later), I'm wondering whether they can even all
> co-exist in the same repository happily enough, or even whether I would
> be better asking for a separate repository for each.

I would put them into different repositories, if only to avoid the odd
effect that changes to 'website a' change the revision numbers of
'website b' files.

> There's then the question of folder structure in the repository.
>
> Can I (sort of) "mirror" the webserver layout from the /data folder
> downwards, bearing in mind that there exist existing files on the server
> that must not be included in the repository and, equally importantly,
> must not be overwritten when the repository contents are checked out or
> updated onto the respective webservers?

You could create the intended directory structure and the versioned
files in svn, check that out and copy the 'alien files' to their
desired locations afterwards. Unless explicitly added to the
repository, subversion will ignore them by default. Another possible
idea would be to keep them in a separate tree and use (versioned)
symlinks in the 'managed' tree to refer to them.

[Lusotec]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It is simple to do what you describe.

1) Create a svn repository (in the machine.
$ svnadmin create /path/to/repo/site2

2) Go to /data/webs/site2/
$ cd /data/webs/site2/

3) Checkout the repository.
$ svn checkout URL/site2 .

4) Check what svn sees in the base directory.
$ svn status

5) Set the ignore rules in the base directory (rules will match the files
and directories names and can use * wild card). In your case just "site" is
needed.
$ svn propset svn:ignore site .

6) Again, check what svn sees in the base directory, to confirm if the
ignore rules are correct.
$ svn status

7) Add all files and directories (except those ignored) to the repository.
$ svn add . --force

8) Explicitly add the "site" directory but not its content (by using the -N
flag).
$ svn add site -N --no-ignore

9) Set the ignore rules for the 'site' directory. In your case "site"
directory needs a ignore rule of "*" to ignore all content.
$ svn propset svn:ignore '*' site

10) Explicitly add the site/stub directory and its content.
$ svn add site/stub --no-ignore

11) Again, check what svn sees in the base directory, to confirm the result.
$ svn status

12) Finally, Commit the files to the repository
$ svn add site/stub

That should do it.

Yes, all sites can coexist in the same repository. The real question is
should they be in the same repository?

My rule of thumb is that if two projects are for the same client and are
related then they should be in the same repository, otherwise separate
repositories are my choice.

> There's then the question of folder structure in the repository.
>
> Can I (sort of) "mirror" the webserver layout from the /data folder
> downwards, bearing in mind that there exist existing files on the server
> that must not be included in the repository and, equally importantly,
> must not be overwritten when the repository contents are checked out or
> updated onto the respective webservers?

I always "mirror" the directory and file layout of the project(s) in the
repository, even when directories and/or files must not be touched/managed.

> (This would possibly involve some horrible 'ignore' properties, assuming
> I understand them properly and it would even be possible?)
>
> From my experience of svn so far, it appears that it expects you to
> create an empty folder where you then check out your working copy,
> which seems to suggest against being able to check out a copy into
> a folder containing existing files (which you do not want to overwrite).

svn has no problems making a checkout to a directory with existing content.
I frequently do that.

> Is my only option then to only start the file structure from the
> top-most folder that will be under version control? (So that the files
> that should not be tampered with are 'above' this level and so are
> safely out of the way?)

Make a backup before doing anything else! Just saying.

> (eg, svn would contain a folder 'php' corresponding to
> /data/webs/site2/php for site2, and [various] folders for the [various]
> "roots" for site1. If site1 had been following "the rules" then its code
> files would also have been in a corresponding 'php' folder, but this
> wouldn't be a unique name at this level, implying the need for site1/php
> and site2/php in the repository (but would that cause the problem that the
> other unmanaged files/folders on the webservers under site1 and site2
> wouldn't be "safe" from over-writing?))

I get the impression that the code you are working with will need some major
reorganization. I would do the following in this situation.

1) Make a backup.
2) Verify the backup.
3) Create a repository.
4) Create a "old" branch and put *all* files in it.
5) Start reorganizing the code by copying from the old branch to trunk and
change paths in code as needed. Use the "svn copy" instead of just file copy
to preserve file history.

Regards.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iF4EAREIAAYFAlGQ5sIACgkQGQjO2ccW76pYDwD/cNaTwVE/jaFBxKElG8K8eJ6p
jXIZP31MoQi+v/0LqAQA/0X/2D7wJNtT9G9OgET4J/K6f7hzAlgUFG1fr8eoyr0W
=sWVm
-----END PGP SIGNATURE-----

[John Gordon]

In <kmqd3k$co1$1...@dont-email.me> David <da...@55952163-3189045.bogus.domain.invalid> writes:

> I'm planning to use Subversion (svn) to manage and deploy website files
> on our development and live websites, but am new to Subversion and so
> would be very grateful for some advice..

Subversion is good for managing the files (i.e. keeping track of revisions),
but I wouldn't use it for deployment. Something like rpm is much better
suited for that task.

--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"