Automatically append log on post-commit

[azredwing]

Hi all,

I realize what I'm about to ask for pretty much flies in the face of all that SVN stands for, so let me give you some backstory first.

I am part of an aerospace club at my university that is being run much like a real aerospace company, complete with full revision control and such. Configuration management is extremely strict, which is not what SVN was built for of course. I was tasked with switching us from a non-existent revision control system to SVN.

When I say extremely strict, here's what I mean:
-Commits must be approved by an admin before SVN can allow it - this means getting paperwork filled out and signed by a member of a dedicated config management team member
-All changelogs must be non-empty.

I'm pretty decent with Perl, so both wasn't so difficult. Essentially, admins run a script that generates an approval code, and emails to the admin and the committer are sent out with that approval code. The approval code is stored along with admin information in a .CSV file that cannot be accessed by non-admins (only admins have ssh capability to the server). This approval code, and the code only, must be the very first line of your changelog before the server will accept the commit. Not terribly difficult.

Now, here is my problem: On post-commit, I'd like to remove the access code from the log and append the log with information about the approving admin. See the below code (Perl). If you need to know what's in my modules, let me know. I just don't want to post unnecessary information...

#!/usr/bin/perl

# post-commit
# Automatically sets changelog to remove the approval code and append admin information

# the repository is in /specworks/sandbox

use strict;
use warnings;

use lib '/specworks/admin/perllib';

use SpecWorks::Admin;
use SpecWorks::Code;
use Carp;

# Prepare databases
my %codes = Code::retrieve_list();
my %users = Admin::retrieve_roster();
my ($repo_path, $rev_num) = @ARGV;

# Retrieve the entire log file; remove the approval code and perform updates
chomp(my @log = `svnlook log $repo_path -r $rev_num`);

my $user_code = shift @log;

my %approval = ( 
    admin    => $codes{$user_code}{admin   },
    date     => $codes{$user_code}{date    },
    comments => $codes{$user_code}{comments},
);

my %admin_info = Admin::find_user($approval{admin}, \%users, {admin_only => 1,});

# Start writing approval information

my $admin_info = <<"EOF"; 

========
Approval information:
Approval code   : $user_code
Admin           : $approval{admin}
Admin email     : $admin_info{email}
Time of approve : $approval{date}
Comments        : $approval{comments}

EOF

push @log, $admin_info;

my $log_single_line = join "\n", @log;

# Attempt to write the changelog - pre-revprop-change will only work if the approval code given is still in the database
my $successful_edit = system qq{svn propset svn:log --revprop -r $rev_num "$log_single_line" $repo_path};


if (! $successful_edit){
    die "Couldn't append approval information to changelog!\n";
}
#If we get this far, then the user's commit attempt is legitimate. Delete the old code from the list.
Code::remove_from_list($user_code);

Everything works correctly up to the attempted propset, which is of course the entire point of this post-commit script. The script always dies at that system() call:

svn: /specworks is not a working directory

I figure the issue is that svn propset does not take $repo_path as an argument, but instead takes the actual path to the repository (call it svn://my_repo.com:3690/sandbox). Placing that in there doesn't work either, though.

Right now, pre-revprop-change is set to always return success. My only concern at the moment is getting properties set on post-commit.

So, any ideas on how to append logs on post-commit?

Thanks for your help!

[andyl]

Configuration management is extremely strict, which is not what SVN was built for of course. I was tasked with switching us from a non-existent revision control system to SVN.

If you think that Subversion isn't well-suited to your requirements (although I would disagree with the above statement), why are you using it in the first place?

[azredwing]

Configuration management is extremely strict, which is not what SVN was built for of course. I was tasked with switching us from a non-existent revision control system to SVN.

If you think that Subversion isn't well-suited to your requirements (although I would disagree with the above statement), why are you using it in the first place?

I don't mean that it's not a good choice. It's an excellent choice, but what I'm doing is "unnatural" for SVN. For instance, I thought that commits were free to make, but it turns out all commits must be approved. Also, we are using lock-modify-unlock as opposed to merging revisions and such. It's just much more strict than I thought necessary for SVN. It's not hard to make SVN do stuff strictly with hooks, though.

[andyl]

The control requirements are probably not exactly as you've stated here. Can you have developers working on their own private branch, and only a single approved person/group merge those changes into the "official" line of work (trunk)?

Again, I ask - if what you need to do runs counter to Subversion's functionality & features ("unnatural for Subversion" as you say), then why use it?

I'm a strong proponent of SVN, but I'm first and foremost in the camp of "pick the right tool for the job".

[azredwing]

The control requirements are probably not exactly as you've stated here. Can you have developers working on their own private branch, and only a single approved person/group merge those changes into the "official" line of work (trunk)?

This is possible, I'll ask my team about this. I don't think this is what they had in mind.

Again, I ask - if what you need to do runs counter to Subversion's functionality & features ("unnatural for Subversion" as you say), then why use it?

I'm a strong proponent of SVN, but I'm first and foremost in the camp of "pick the right tool for the job".

Honestly, I don't know what else to use. The system before was FolderShare, which had no revision control at all, and one persons' edit was reflected immediately in everyone's share, and there have been times where the entire share was accidentally deleted. There's no concept of checking out or committing - once you edit a file, that file is permanently edited.

In any case, I don't know what other revision control system to use that is free/open-source that implements strict config management, not to mention I've already trained my people how to use TortoiseSVN (all our CAD stuff is on Windows). I've built quite a few hooks already and the control system I instantiated on top of SVN to check for administrative rights, etc., is in place, tested, and ready to go. Plus, SVN does give the config management team things like changelogs (which we're strictly enforcing), who edited what, when, etc. There's a lot that SVN offers us that we did not previously have.

Whether or not SVN is a good choice for our project is irrelevant, however. I do appreciate your input. But the point of my question was simply to see if there's a way to do property changes on post-commit and post-commit only. That's the long and short of the matter.

[azredwing]

I figured it out. I'm using authentication to the SVN sever, but the post-commit hook was running for 'root' and 'root' was not in the passwd file. Adding a root with no password corrected it immediately.

Thanks for help.

[mithatcan]

I figured it out. I'm using authentication to the SVN sever, but the post-commit hook was running for 'root' and 'root' was not in the passwd file. Adding a root with no password corrected it immediately.

Thanks for help.

Hi azredwing,

Thanks for your great share on this.
Would it be possible to share your admin code generating mechanism if it doesn't disturb your university/firm policy?

Many thanks in advance!

Mithat

[andyl]

Hi azredwing,

Thanks for your great share on this.
Would it be possible to share your admin code generating mechanism if it doesn't disturb your university/firm policy?

You're replying to a 3 1/2 year old thread, he may not even be employed there anymore.

His Subversion server was not configured safely in the first place, services like that should not be configured to run as root. So I would recommend against emulating what he may have done there. In the hook script, simply pass --username and --password to the svn client to use appropriate credentials.