Many many years ago (I'm dating myself) I worked on an SCC system (can't
recall the name) that got around this quite well. Basically (to
translate a little) it had the ability to execute server hook scripts on
the *client*. This is, an admin could author a hook script, place it on
the server, and then all clients would automatically upload and run that
hook script at the specified event. Now, this model is obviously one
that could be abused, and has issues with cross-platform clients, but I
liked the model because (a) it scaled well (server overhead was lower)
and (b) a lot of smarts could be injected that were based around
individual best practices for the particular group.
Just a thought (wish?)...
--Tim
Weintraub, David wrote:
> From: Ben Collins-Sussman
> > On Apr 22, 2005, at 11:11 AM, Weintraub, David wrote:
> >
> >> Actually, even if you specify all possible text file patterns, you
> >> still have a problem. What if a user does their work on a system where
> >> you didn't setup the autoproperty for them?
> >>
> >> This points to several missing features with Subversion:
> >>
> >> 1). No server side configuration. You have to basically set up this
> >> configuration on all client machines. What if the user overrides this
> >> configuration? What if the user decides to do work from home on his
> >> personal computer where you did not setup this client configuration?
> >> What happens when a machine gets replaced?
> >
> > This is planned for 1.3. It's a hot item.
>
> Yea!
>
> >> 2). Limited power of the svnserve and svnlook commands. Hooks can be
> >> used to enforce policy, so maybe you'll program a post-commit hook
> >> that examines a file that gets committed, and automatically sets the
> >> svn:keyword property if it isn't already set. Oops, the propset and
> >> propget commands don't work without first creating a working directory
> >> and checking out that file in that working directory. A hook doesn't
> >> work.
> >>
> >
> > You've got it backwards. You should be using a *pre*-commit hook to
> > reject any commit which doesn't have properties set correctly. It can
> > send a nice message back to the use explaining why the commit was
> > rejected.
>
> Yes, I can reject the commmit, but it makes me feel like I'm working
> for the DMV. Instead of simply being able to reject, I'd like fix the
> problem.
>
> After all, I'm so close... After rejecting the commit, I can send the
> developer the actual command to use and tell them to cut and paste it
> into their command line. I just can't run the command myself.
>
Received on Fri Apr 22 20:04:38 2005