[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Pre-commit and post-chekout hooks on client side

From: m christensen <dfs_at_xmission.com>
Date: 2004-09-08 19:10:48 CEST

Waldemar Augustyn wrote:

> That's because the scripts use rule sets and distributing them to
> clients is really not under consideration.
>
> There is this idea of having clients pull the scripts from the server
> on demand. This would require a wrapper or a client-side hook.
> Rather ugly.
>
> I think, the way to go is to use a post-commit hook that triggers a
> checkout-modify-checkin cycle on the server side on behalf of the
> original user. A bit involved but doable.
>
> BTW, I am having hard time believing the clients would get messed up.
> They really have to do an implicit 'status' to claim correspondence to
> any particular version. Do they get just a version number back?
> Maybe they should get a diff along with it instead of assuming perfect
> synchronization.
>
> Whatever the case, I think this points out to some missing
> functionality svn might want to consider adding.
>
Well, this comes back to my original statements regarding sync. times.

My repository contains 28,000 files.
I DON'T want the damn thing diffing, checksumming, comparing or
otherwise validating 28,000 files between
my working copy and the repository every time it syncs up.

The fact is I just comitted version X of the repository from my working
copy.
By definition until X is incremented my working copy is current.
If X is incremented deduce what I need from repository update logs and
send me those files.

That logic is prefectly valid and saves a LOT of time and work at each
commit or local update.

The simple rule required to keep thing working correctly is also simple
and perfectly
valid for MANY reasons.
That rule is:
When I commit new files or changes either add ALL of them to the repository
or Add None of them and inform me of the failure.
Don't muck with what I sent and commit something else!

If YOU want to make a change follow the same rules you expect ME to follow.
If YOU Change code, commit those changes with valid comments just like
I'm required to.

It provides an audit trail.
It provides accountability.
It provides a recovery path.

When YOUR modification scripts hose MY code that has been loving
crafted, tested and certified to
work and commits crap to the repositoty, I'm left holding the bag and MY
source code is gone.
IF you can get the system to recognize the fact it was changed in
transit and therefore 'Fix' my local
working directory ALL my work is gone forever.

Just follow the same rules you expect me to follow.
Get my offending code, change it and commit the changes with a valid
change description.

When my code blows up at the next build it's very simple to determine
why and who made the offending changes.

SVN is not CVS, the mindset is changed for the better IMHO take
advantage of the improvements.

.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 8 19:11:52 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.