Here are two scripts which I wrote for a project that got cancelled,
and so they arn't very well tested and arn't terribly well documented,
though I hope the comments are useful.
However, they should;
1. cope with symlinks (as an svn property of directories)
2. cope with device special files (again, as an svn property of
directories)
3. cope with (*nix) permissions and ownerships (as svn properties of
files and directories)
4. not cope with pipes and sockets; these don't get backed up by tar
anyway and so daemons et.al. *should* recreate them as needed.
5. it appears to cope with file and directory names with spaces and
other funny characters.
So, the filesystem properties, mode, gid, uid, symlinks, devices and
their mode, uid, gid are all versioned in svn properties;
dir:mode, file:mode
dir:uid, file:uid
dir:gid, file:gid
dir:symlinks
dir:devices
To use;
1. ensure that your working copy has appropriate perms/ownerships.
2. run svnpropset.pl in the working copy; it will traverse the directory
creating and/or setting the svn properties.
3. commit the changes
4. when you have checked it out elsewhere, run svnpropget.pl in the
working copy.
It *should* recreate symlinks and devices and set ownerships and
permissions. Uh you will probably need to be root for this to work.
I am a rank beginner with perl and svn so feedback would be appreciated!
And don't blame me if you run this on a production system and lose
stuff!
The component of the project for which these were intended was to manage
the /etc directory of workstations. These scripts were originaly
intended to also create cfengine scripts as well, and though this was
stripped out, there may be some traces left.
On Tuesday 22 June 2004 17:05, Steven Brown wrote:
> Jani Averbach wrote:
> > On 2004-06-21 20:58-0700, Steven Brown wrote:
[big snip]
>
> The problem is that Subversion can't understand (currently) the full
> structure of /etc, like symlinks (I'm not sure how well it deals with
> devices and sockets/pipes). Debian uses a lot of symlinks in there
> (e.g., Apache 2). So to fully Subversionize the directory, a script
> to capture and rebuild structure that couldn't be saved directly is
> needed, which starts breaking down the glamour of version control.
> Since I can't use it to fully version or backup the directory, I
> start comparing it to other partial solutions, and in that space, I
> feel the traditional admin 'RCS, backups, and changelogs' solution
> for is still the way to go. Since the majority of program
> configurations are self-contained in one file, there's very little
> lost feature-wise compared to a tool that can handle multiple files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 23 17:24:27 2004