> = David Weintraub
@ = Max Bowsher
> This brings up another problem with Subversion: The Admin has little power
> to enforce CM standards. I am basically given a single big stick: I can
> prevent someone from committing a change I don't want. But, there is
> little else I am allowed to do.
>
> For example, if someone does a commit, I'd like to prompt them for a
> defect ID. Yes, I know that the TortoiseSVN client can do this, but what
if I
> want to make sure it is enforced on the server side, and not depend upon a
> particular Subversion client?
@ And how exactly is the server going to influence the client in this way?
That's the big question. How do you get the server and client to communicate
in a conversation? The client and server are already communicating. The
client is sending a file to the server, and the server send's its STDERR and
the commit status to the client. But, that's it. There is no back and forth
conversation.
> What if a developer creates a new file, and
> doesn't set the property svn:keyword = "Id" on it? Or, if a file is text,
> make sure it contains a copyright string inside of it?
@ Then complain, and reject the commit.
I do that already, but it gives the project a very bureaucratic flavor. It
would be nice if you could guide something like this along.
> Some of this could be done with an expanded svnadmin command that would
> allow an administrator to do all of the things that svn can do without
> first
> creating a working directory.
@ Why?
So, the administrator can run jobs that might do such things as add
properties without having to create a working directory first. That can take
time and diskspace. We already allow certain commands like "mkdir" to be run
without creating a working directory. The administrator should be able to do
whatever want to the source repository without having to first create a
working directory.
> Others would require some way for the server
> to examine the version of the file that is sitting on the client's machine
> without that version of the file being added to the source archive.
@ Already possible during pre-commit hook. The proposed commit has been
placed
@ in full as a transaction in the repository, and the pre-commit hook can
@ examine it.
@ "svnlook cat -t $TXN ..."
Can the pre-commit hook (via the svnlook command) examine the source code?
We had a policy that all non-binary files must have a particular copyright
meessage in them. How could Subversion do that?
In ClearCase, it was pretty easy to write a trigger to do this. You grep the
file for the copyright string, and if it wasn't there, reject the check-in.
Heck, that's how we had ClearCase expand RCS keywords. On a check-in,
ClearCase would go through the file and rewrite it with the expanded
keywords, then check it in.
Of course, the ClearCase hook ran on the client machine and not the server,
so it was easy for the trigger to examine the proposed check-in. But, in
order for the trigger to work, we had to make sure that the client machines
were correctly configured. Imagine an environment where you were running
four different flavors of *nix, and each flavor or *nix could have 3 or more
different OS versions, and you have PCs running various flavor of Windows.
Now, imagine running a trigger script that would work on all of them. Plus,
you have to make sure that no one did something to deactivate your trigger
scripts. We had Perl trigger scripts and one developer created his own
"perl.exe" command that would always allow the trigger to successfully check
in his files. He setup his own PATH to pull his "perl.exe" before the
"perl.exe" that was on the system.
Nope, I'd rather have the server run the hook scripts. As far as I am
concerned Subversion does it the right way. Of course, that means you can't
examine the file before it gets checked-in. At least not the way the client
and server now communicate with each other.
I realize that all this will involve a lot of rewriting and rethinking in
Subversion. This will not be an easy task for the Subersion development team
to do. But, issues like this, like the server side client configuration, and
like the "rmversion/obliberate" command sets are things that are availiable
and very useful in other version control systems, but are missing in
Subversion.
Maybe these issues could be resolved by the time Subversion 3.0 comes out.
Received on Fri Apr 15 19:15:14 2005