Subversion trials and errors

Late yesterday I tried

$ cd htdocs
$ svn import -m "New import" file:///usr/local/svn/newrepos

which then started processing (what exactly was done?) many large files in the htdocs tree which, on reflection, I don't want in the repository (archived Apache access logs(!), movies which are never revised, etc.). The import then choked on a file for which permissions were wrong.

Two questions now:

1. How to undo all the processing that was done? (Maybe nothing was done since it choked?)
   
2. How to do it better next time?
   

I don't think that the huge files were actually copied to another location on the filesystem, since this shows that the space is unchanged (if they'd all really been copied, Used should have almost doubled):

$ df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             131G   27G   98G  22% /

And it looks like the best way to undo is to use a system (not svn) rmdir. stspiffy says,

you can svn delete directories, but if you want to get rid of the entire repo forever-ever, ... the correct way to delete a repository is actually to delete the directory.

As far as How to do it better next time,

1. I think www, not htdocs, should be the 'root' of the project (so that libraries and other (admin, etc) servers are included in the same repository)
   [ah but maybe it's better to have separate repositories? probably not, if it makes updates and commits harder. (But it doesn't, right, since these commands don't require the repository url?) So actually, at an extreme, I could have separate repositories (with granular revision numbers) for each directory in htdocs!] Is it reasonable to have one repository for libraries (which hardly ever change) and another for htdocs (which change 1-4 times/year) and another for the clearinghouseAdmin server, etc? 
   
2. I could move archived access logs out of this tree. But what to do with other bulky files?
   
3. Probably the best thing to do is vi a folder-by-folder svn import script (vi, :r !ls, :%s/^.*$/svn import -m "New Import" & file:///usr/local/svn/newrepos, zap unwanted lines from the file and then run as a script)
   

Subversion notes

We have an existing project (web site).
We want to start using Subversion (svn) to document (and be able to undo) changes.
We have installed svn version 1.4.4 (r25188).
We need network access to the repository, at least for Daniel. (I may just continue editing on the server.)
Q: Which Subversion server process are we running? We have two choices. Quoting the Subversion FAQ:

either svnserve, which is small standalone program similar to cvs pserver, or Apache httpd-2.0 using a special mod_dav_svn module. svnserve speaks a custom protocol, while mod_dav_svn uses WebDAV as its network protocol.

Integration with Dreamweaver: it looks like DW CS4 will support svn.

Subversion User Best Practices

Policy

We use an Unstable Trunk policy.

• Most development happens in the trunk (Live web site).
• Don't break the trunk!
• Bugs are found - by our users if we miss them! - and fixed quickly.

Alternative: do work on a branch, and later merge changes.

• Means more merging.
• A lot more merging.
• Easier to ignore what other developers are doing :-(
• Always-Branch policy typically used in a heavily centralized situation where a supervisor OKs each coder's work (branch) before it is merged.

I think we might branch if we were going to change the whole site, e.g. PHP->Java, or a fundamental change to the way we INCLUDE navbars etc.

Commits

• Commits are good; commit each discrete thing you do. "Commit as soon as your changes makes a logical unit. ... To make it simple: your SVN comments shouldn’t explain that you did more than one thing. If your SVN comment looks like “Fixing bugs #1234 and #1235″ or “Fixing bug #4321 and correcting typo in debug string” then you should’ve used two commits." - Salvatore Iovene (http://www.iovene.com/5-svn-best-practices/)
• Don't commit to "save your work" at the end of the day.

Comments

Any communication tool becomes useless if you send garbage through it.
So you need to make sure that people can understand your changes.

• Each change should be self-contained.
• The log message should contain useful information.


• What did you change.
• Why did you change it.
• Include filenames touched and functions modified.
• Make it possible to grep the logs later when looking for something.

Draft Subversion email

Decisions:

o Keep the repository (repo) on www or on another server?

++ I vote for "on www." What Randall recommended: make the live htdocs/* folders a checked-out instance of the repo, so that we can make and check-in tiny changes right in those folders

o Repo storage:
Berkeley DB-based
FSFS-based

++ I vote "FSFS." (This is now the default.) Berkeley DB is a legacy holdover, and has corruption vulnerabilities.

o Remote access:
Since we have already set up ssh accounts, it's simplest/safest to use svn+ssh: the svn client opens a ssh session, which then spawns an svn process *as the ssh user* (This means that 1. repository must be owned by a group the user is a member of, 2. the repository must be group-writable, 3. the user's PATH must include the path_to_svn_libraries (/usr/bin/ on www).) I don't really understand this: there may also be umask issues where svnadmin? commands run by a user with the wrong umask set may not be group-writable.
via svnserve daemon (problem: passwords are stored as cleartext.)
via ssh tunnelling
via Apache/webdav
* regular system users using a Subversion client (as themselves) to access the repository directly via file:// URLs;
* regular system users connecting to SSH-spawned private svnserve processes (running as themselves) which access the repository;
* an svnserve process - either a daemon or one launched by inetd - running as a particular fixed user;
* an Apache httpd process, running as a particular fixed user.

++ I vote Apache/webdav: (right? I think that Windows users can just open a webdav resource in a Windows Explorer window.)


o what user/group will own the repository? web:web? do we want to create user:group svn:svn?

What data do you expect to live in your repository (or repositories), and how will that data be organized?
text files, binaries (pdf, jpeg, gif, wmv)
/export/www/* (one project root or two?)
o single repository for multiple projects, or to give each project its own repository?
/export/www/
clearinghouseAdmin/
htdocs/
htdocs-cp2info/
mediaLibrary/
phplib/
railsDevelopment/
ttplib/

? ? Maybe:
repository : Path
www : /export/www/htdocs (pages on www)
www-lib : /export/www/ (ttplib, phplib, admin tools etc)
++ actually, I vote for all in one: they are all related, and we should be able to to ask about (or modify, or migrate elsewhere) the entire history of a single project

Where will your repository live
www server
and how will it be accessed?
directly (command line), network server (WebDav?)
repository browsing interfaces

e-mail commit notification

data backup strategy
backed up with www backups? Right?
What types of access control and repository event reporting do you need?

Which of the available types of data store do you want to use?
FSFS