Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.apps > #594

Re: Using Subversion (svn) to manage website files?

Cross-posted to 3 groups.

Followups directed to: comp.os.linux.misc

Show all headers | View raw

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

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..]
> 
> 
> 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.

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.

> "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.

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-----

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Using Subversion (svn) to manage website files? David <david@55952163-3189045.bogus.domain.invalid> - 2013-05-13 09:51 +0000
  Re: Using Subversion (svn) to manage website files? crankypuss <crankypuss@nomail.invalid> - 2013-05-13 05:16 -0600
  Re: Using Subversion (svn) to manage website files? Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-05-13 14:00 +0100
  Re: Using Subversion (svn) to manage website files? Lusotec <nomail@nomail.not> - 2013-05-13 14:12 +0100
  Re: Using Subversion (svn) to manage website files? John Gordon <gordon@panix.com> - 2013-05-15 21:55 +0000

csiph-web