Weintraub, David wrote:
>
>
> > = 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.
The only possible solution I see now would be to have a wrapper on the
client that examines these things and begins a dialogue with the user
so that everything is fixed before anything is sent to the server.
In this scenario the hook would only be there to make sure that no one
tries to not use the wrapper. Somehow I feel that this is a bit, hmm,
unelegant(?).
> > 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.
Subversion is not allowed to *modify* a file before checking it in,
because of the (IMHO good) reason that the "checked in" version of the
file would be different from the one that the user wants to commit.
> 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.
:-) I would be happy if the server could send an answer to the client when
the commit should be accepted. This would be the first step...
Then one could think of modifying a file and report to the client "Commit
accepted with changes, please do 'svn update' before you continue" or
something alike.
Most likely the developers thought of this and decided against it...
Sorry for bringing it up (again).
Have fun
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 19 12:50:58 2005