Yes, this would be very valuable!  If this became an alternate repo for lenya
(like jsr 170), we could also utilize the versions, properties that svn maintains

(In reply to comment #1)
> If this became an alternate repo for lenya
> (like jsr 170), we could also utilize the versions, properties that svn maintains

That would of course be great, but I think we could start with a simple
synchronization, i.e. commit everything that changes (including the Lenya rcml
files). That would allow to backup and restore the exact state of a website.

ATM every change adds and removes backup files. This makes it a PITA to sync the
content with SVN. Maybe we could add an option to store all backups in a single
file, or at least use non-changing file names (backup-1 .. backup-n)?

(In reply to comment #3)
> ATM every change adds and removes backup files. This makes it a PITA to sync the
> content with SVN. Maybe we could add an option to store all backups in a single
> file, or at least use non-changing file names (backup-1 .. backup-n)?

i don't think this makes much sense. even if you had persistent unique file
names, *all* old versions would pile up in svn, cluttering your repository in no
time. it is never advisable to pile two different mechanisms on top of one
another that both attempt to do the same yet are agnostic of each other (think
of tunneling tcp/ip over tcp/ip as some VPNs do - two layers of transport
control inevitably mess things up).

we should either make svn our main repository and get rid of backup files
altogether, or discourage using svn on our existing repo.

what you could do if you need to get things done is instruct svn to only pull
the current versions and ignore the backups. that would enable you to get a
reasonably complete revision history in svn, provided you pull more often than
users update, or you are content with snapshots at fixed intervals regardless of
missing the odd update.

(In reply to comment #4)
> (In reply to comment #3)

[...]

> we should either make svn our main repository and get rid of backup files
> altogether,

Implementing that would be overkill for my usage scenario (small company website).

> or discourage using svn on our existing repo.

But SVN is so convenient ...

> what you could do if you need to get things done is instruct svn to only pull
> the current versions and ignore the backups. that would enable you to get a
> reasonably complete revision history in svn, provided you pull more often than
> users update, or you are content with snapshots at fixed intervals regardless of
> missing the odd update.
 
Good idea, I'll give this a try.

BTW, this issue will certainly become important when we start to manage the
Lenya website with Lenya.