Yes, SVN way is better.
There is just some funcionality that's not there. So far, it seems, a
post-commit cycle is the best approach to deal with it. In this way the
28,000 commits go as scheduled and are followed by a smaller, but
potentially the same, number of new transactions. That's OK. The point
about exposing modifications made by scripts is valid. The resulting
diffs will come back later, on the first 'conflict', but all versions
are preserved, the trail is clear, and local clients are not confused.
There is no way to avoid the volume of diff-ing and sync-ing, however,
it's just a matter of when and by whom.
m christensen wrote:
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 8 20:11:20 2004