You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brett Wooldridge <br...@riseup.com> on 2004/02/11 23:18:53 UTC
Pre-commit transaction modification question
I'm migrating from CVS to Subversion and am in the process of porting
my 'hooks'. I have a code-formatter (Jalopy), that I need to run as a
pre-commit hook, to format the code as it goes into the repository. Under
CVS this was rather trivial, but I'm having a hard time figuring out how to
do it under Subversion.
Given that Subversion is getting pretty widespread use, I'm guessing that
someone has already cracked this nut. I'm guessing, but am not sure, that
I need to use the SWIG interfaces (say, Python) to accomplish this. Is
this correct? Can someone point me to the interfaces I'll need? I've
figured
out how to get a copy of the code being commited -- and therefore I can
format it -- but I can't figure out how to update the source in the
transaction.
Any help, pointers, and advice is appreciated.
bw
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-02-11 at 19:57, Brett Wooldridge wrote:
> I really want to move our organizationto Subversion, I
> believe in it's principles, I see value in it's features, and I want to
> see it thrive -- but it can't represent a step backward for the
> processes that we have in place.
I'm not sure how we can help. You've got the classic problem: you have
a bunch of coders that need to be educated and disciplined, and you've
been forced to use a specific technology as a "cover up" because
management doesn't want to deal with the real problem directly.
I doubt SVN will ever grow this particular feature, because most svn
developers think it's a Bad Thing. If this is a 'showstopper' for your
adoption, I guess that's that. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Philip Martin <ph...@codematters.co.uk>.
David Ripton <dr...@ripton.net> writes:
> Is it okay if a checkin generates two versions of a badly formatted
> source file, the ugly one exactly as checked in by the user and then a
> clean one?
It's OK for the post-commit to trigger another commit, but there are
some complications.
1/ The post-commit is asynchronous so there is a race:
- R1 commit completes
- R1-post-commit starts building a commit R1'
- R2 commit completes
- R1' attempts to complete but may fail due to R2
2/ You need to take care to avoid loops. It's probably a good idea
to take steps to ensure that any "automatic" commits triggered by
a post-commit cannot trigger another "automatic" commit. Perhaps
by using a separate user ID for the automatic commits and have
the post-commit ignore commits by that user.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by David Ripton <dr...@ripton.net>.
Brett Wooldridge wrote:
> I appreciate the suggestion, the problem is that some users use
> Tortoise, other's Eclipse integration, and other's still (those hardcore
> emacs users) command line. Getting people to voluntarily format their
> code was tried and was a miserable failure (at least is our
> organization) -- you know, herding cats and whatnot. A style checker is
> only slightly more attractive, and would probably last about five
> minutes until developers started complaining to their managers about
> having their code rejected five times and what a burden it is on their
> productivity. We have some coders with truly awful style, and
> management has the spine of a noodle -- so if it isn't painless for all
> involved, it's not going to fly. So far, CVS has served us very well in
> this regard. I really want to move our organizationto Subversion, I
> believe in it's principles, I see value in it's features, and I want to
> see it thrive -- but it can't represent a step backward for the
> processes that we have in place.
Is it okay if a checkin generates two versions of a badly formatted
source file, the ugly one exactly as checked in by the user and then a
clean one?
If so, you could write a little script that is triggered post-commit.
It would svn update its own working area on the server, see if any files
that were just updated matched the criteria for needing reformatting
(e.g. "*.java" or "*.c"), run the correct formatters on those files, do
a svn diff to see if the reformat actually changed anything, and do a
svn checkin if necessary with a standard commit message like "janitor
bot cleaning up after $USER's checkin r1234"
The developer who just did a checkin would have to do an svn update to
get the formatting changes, but if he forgot and kept working on the
ugly files, it would be a trivial merge later. Users who didn't like
this would have incentive to run the formatter locally before checking
in files.
--
David Ripton dripton@ripton.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Brett Wooldridge <br...@riseup.com>.
I appreciate the suggestion, the problem is that some users use
Tortoise, other's Eclipse integration, and other's still (those hardcore
emacs users) command line. Getting people to voluntarily format their
code was tried and was a miserable failure (at least is our
organization) -- you know, herding cats and whatnot. A style checker is
only slightly more attractive, and would probably last about five
minutes until developers started complaining to their managers about
having their code rejected five times and what a burden it is on their
productivity. We have some coders with truly awful style, and
management has the spine of a noodle -- so if it isn't painless for all
involved, it's not going to fly. So far, CVS has served us very well in
this regard. I really want to move our organizationto Subversion, I
believe in it's principles, I see value in it's features, and I want to
see it thrive -- but it can't represent a step backward for the
processes that we have in place. Help me help Subversion succeed in my
organization. I'm a senior developer, with 16 years experience, and a
good skillset, and I'm willing to help where I can to move Subversion
forward.
bw
Bruce Elrick wrote:
> Given the warnings about the server-side pre-commit hook changing the
> transaction causing WC badness, might I suggest you turn to using a
> wrapper on the client side? Implement the format check in the
> pre-commit hook as Ben suggested to prevent people from bypassing the
> wrapper on the client side, but on the client side write a wrapper
> that runs your formatter on appropriate files that are modified, then
> run svn commit from inside the wrapper. You can determine how
> sophisticated the wrapper has to be based on you user's trainability.
>
> That's my naive suggestion.
>
> Cheers...
> Bruce
>
> Brett Wooldridge wrote:
>
>> Ok, arguments about merits aside (as we've been using this model
>> under CVS for over a
>> year without issue) -- I'd still like to know how to accomplish this
>> under Subversion. CVS
>> has the same 'issue', in that after checking in the source, the
>> source in the repository no
>> longer matches the source on the user's system. Again, for our
>> organization, this has not
>> been an issue -- the only side-effect being that an immediate diff
>> will show the differences
>> in formatting, but after an 'update', the work is right again. So,
>> paternalism aside, can you
>> please help me shoot myself in the foot? :-)
>>
>> bw
>>
>> Ben Collins-Sussman wrote:
>>
>>> On Wed, 2004-02-11 at 17:18, Brett Wooldridge wrote:
>>>
>>>
>>>> Any help, pointers, and advice is appreciated.
>>>>
>>>
>>>
>>>
>>> DON'T DO IT.
>>>
>>> If the repository mangles the files as they enter the repository, then
>>> your working copy will be completely wrong. The working copy will
>>> think, "ah, this file I committed is what the latest version looks
>>> like", but in reality, the latest version in the repository is very
>>> different. There's no way for the pre-commit hook to tell the working
>>> copy that it mangled the data. What Subversion people have done
>>> instead is to install a pre-commit hook
>>> which merely *validates* a style, and rejects the whole commit if any
>>> file files to conform. This forces users to run the reformatter.
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: Pre-commit transaction modification question
Posted by Bruce Elrick <br...@elrick.ca>.
Given the warnings about the server-side pre-commit hook changing the
transaction causing WC badness, might I suggest you turn to using a
wrapper on the client side? Implement the format check in the
pre-commit hook as Ben suggested to prevent people from bypassing the
wrapper on the client side, but on the client side write a wrapper that
runs your formatter on appropriate files that are modified, then run svn
commit from inside the wrapper. You can determine how sophisticated the
wrapper has to be based on you user's trainability.
That's my naive suggestion.
Cheers...
Bruce
Brett Wooldridge wrote:
> Ok, arguments about merits aside (as we've been using this model under
> CVS for over a
> year without issue) -- I'd still like to know how to accomplish this
> under Subversion. CVS
> has the same 'issue', in that after checking in the source, the source
> in the repository no
> longer matches the source on the user's system. Again, for our
> organization, this has not
> been an issue -- the only side-effect being that an immediate diff will
> show the differences
> in formatting, but after an 'update', the work is right again. So,
> paternalism aside, can you
> please help me shoot myself in the foot? :-)
>
> bw
>
> Ben Collins-Sussman wrote:
>
>> On Wed, 2004-02-11 at 17:18, Brett Wooldridge wrote:
>>
>>
>>> Any help, pointers, and advice is appreciated.
>>>
>>
>>
>> DON'T DO IT.
>>
>> If the repository mangles the files as they enter the repository, then
>> your working copy will be completely wrong. The working copy will
>> think, "ah, this file I committed is what the latest version looks
>> like", but in reality, the latest version in the repository is very
>> different. There's no way for the pre-commit hook to tell the working
>> copy that it mangled the data.
>> What Subversion people have done instead is to install a pre-commit hook
>> which merely *validates* a style, and rejects the whole commit if any
>> file files to conform. This forces users to run the reformatter.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: Pre-commit transaction modification question
Posted by kf...@collab.net.
Brett Wooldridge <br...@riseup.com> writes:
> I understand. Which is why I wasn't framing it as a 'could you please
> do for me', but rather as
> 'if I do it for you'. I know you guys have other priorities, but
> that's what makes open source tick --
> somebody has an itch for a feature, so *they* build it and contribute
> it back, rather than waiting
> for somebody else to do it for them.
Absolutely -- and thanks for the offer!
But of course, contributed code can't ever entirely take the burden
off the other committers, because they still have to review &
understand the change. This is true even if someday the contributor
becomes a committer themselves.
So yah, feel free to post a patch (or a design first), the simpler the
better. I mainly wanted to warn you that it would be a tough sell,
since I don't know your particular "risk of wasted time" threshold.
Now that you know, it's entirely your call.
Good luck,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Brett Wooldridge <br...@riseup.com>.
kfogel@collab.net wrote:
>Whoa whoa whoa... Hold up one minute, Tex :-).
>
>
How did you know I was from Texas? :-)
>Let me clarify something:
>
>We're not suggesting that these client-side workarounds are *better*
>from the developer's point of view, nor that it's somehow more morally
>correct to simply reject the commit and force the developer to solve
>the problem before trying again.
>
>Rather, what we (or at least I) am saying is: the server-side-txn-mod
>solution is *hard* to implement correctly in Subversion, and the extra
>complexity it adds to Subversion may not be worth the benefit to
>users.
>
>
I agree. Let me take it as a challenge to see how simple I can make the
implementation. In the
end it may get rejected due to complexity. But complexity is a relative
thing. Adding DFS support
to Samba was complex. :-) From what I've seen of the codebase,
everything is pretty straightforward
and the implementations very concise.
>Notice that this does not deny that there is some benefit to users.
>But it also takes into account the implementation and maintenance
>burden of the feature... Which is something we think about for every
>feature. If features didn't cost anything, then this whole mailing
>list would be unnecessary.
>
>
Agreed.
>When we suggest workarounds, they're exactly that: workarounds. I'm
>not saying you should prefer them to the ideal solution. I'm asking
>if you can live with them, because the ideal solution may not make it
>to the top of the developers' priority stack anytime soon.
>
>
I understand. Which is why I wasn't framing it as a 'could you please
do for me', but rather as
'if I do it for you'. I know you guys have other priorities, but that's
what makes open source tick --
somebody has an itch for a feature, so *they* build it and contribute it
back, rather than waiting
for somebody else to do it for them.
Thanks,
bw
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by kf...@collab.net.
Brett Wooldridge <br...@riseup.com> writes:
> Yes, I agree, to anticipate your arguments, it could have been
> implemented as a header check
> which rejected files with improper notices. Thus putting the onus on
> developers to obtain the proper
> notice and put it in files they checked in. To which I would ask
> "Why?". Why should developers
> have to do that if that is something that a tool can do for them.
> That is why we have tools; to
> help eliminate repeatitive and automatable tasks. If we had written a
> 'bad' hook that mucked up
> the files, it's our repository, it's our fault.
>
> This is like a basic liberatarian principle. Don't protect me from
> myself. Let me have the power
> and flexibility to make the changes I see fit in my environment. In
> no way does this violate the
> integrity of transaction or compromise the integrity of the
> repository. It can be implemented in
> a way that is completely transparent to the user and is literally a
> no-op when the transaction
> goes un-modified.
Whoa whoa whoa... Hold up one minute, Tex :-).
Let me clarify something:
We're not suggesting that these client-side workarounds are *better*
from the developer's point of view, nor that it's somehow more morally
correct to simply reject the commit and force the developer to solve
the problem before trying again.
Rather, what we (or at least I) am saying is: the server-side-txn-mod
solution is *hard* to implement correctly in Subversion, and the extra
complexity it adds to Subversion may not be worth the benefit to
users.
Notice that this does not deny that there is some benefit to users.
But it also takes into account the implementation and maintenance
burden of the feature... Which is something we think about for every
feature. If features didn't cost anything, then this whole mailing
list would be unnecessary.
When we suggest workarounds, they're exactly that: workarounds. I'm
not saying you should prefer them to the ideal solution. I'm asking
if you can live with them, because the ideal solution may not make it
to the top of the developers' priority stack anytime soon.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Brett Wooldridge <br...@riseup.com>.
This issue with this is that it creates additional revisions in the
repository. The expected behavior
by the user is that a diff between two subsequent versions will show
only the code that changed.
In the method below, the user needs to diff two versions back to
actually perform a semantic diff,
because the immediately prior version would just be the unformatted
file, not the real last revision.
bw
Szekeres Istvan wrote:
>This can also done automatically without any hooks. Just write a shell
>script that checks out the repository (or updates a working copy), checks the
>headers and updates them if necessary, then commits the changes.
>
>Of course this is not so real-time as the header updates done at commit
>time, but I think it is still acceptable.
>
>
>Istvan
>
>
>
>>As an example of the kinds of CVS hooks I've seen in the past at places
>>I've worked, and
>>an example of where such modification might be considered desirable by
>>SOME users: the
>>last place I worked was very concerned about proper legal notices
>>(headings) being in files.
>>The legal department saw fit to change what they wanted in those headers
>>on what seemed
>>like a release-by-release basis. A CVS hook (in perl) was written that
>>inserted the legal
>>notice at the head of every file; if the notice that was there didn't
>>match the new one, it was
>>replaced. This was done at checkin, transparently to the developer.
>>
>>
>
>
>---------------------------------------------------------------------
>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
Re: Pre-commit transaction modification question
Posted by Szekeres Istvan <sz...@pulsussoft.hu>.
This can also done automatically without any hooks. Just write a shell
script that checks out the repository (or updates a working copy), checks the
headers and updates them if necessary, then commits the changes.
Of course this is not so real-time as the header updates done at commit
time, but I think it is still acceptable.
Istvan
> As an example of the kinds of CVS hooks I've seen in the past at places
> I've worked, and
> an example of where such modification might be considered desirable by
> SOME users: the
> last place I worked was very concerned about proper legal notices
> (headings) being in files.
> The legal department saw fit to change what they wanted in those headers
> on what seemed
> like a release-by-release basis. A CVS hook (in perl) was written that
> inserted the legal
> notice at the head of every file; if the notice that was there didn't
> match the new one, it was
> replaced. This was done at checkin, transparently to the developer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Brett Wooldridge <br...@riseup.com>.
As an example of the kinds of CVS hooks I've seen in the past at places
I've worked, and
an example of where such modification might be considered desirable by
SOME users: the
last place I worked was very concerned about proper legal notices
(headings) being in files.
The legal department saw fit to change what they wanted in those headers
on what seemed
like a release-by-release basis. A CVS hook (in perl) was written that
inserted the legal
notice at the head of every file; if the notice that was there didn't
match the new one, it was
replaced. This was done at checkin, transparently to the developer.
Yes, I agree, to anticipate your arguments, it could have been
implemented as a header check
which rejected files with improper notices. Thus putting the onus on
developers to obtain the proper
notice and put it in files they checked in. To which I would ask
"Why?". Why should developers
have to do that if that is something that a tool can do for them. That
is why we have tools; to
help eliminate repeatitive and automatable tasks. If we had written a
'bad' hook that mucked up
the files, it's our repository, it's our fault.
This is like a basic liberatarian principle. Don't protect me from
myself. Let me have the power
and flexibility to make the changes I see fit in my environment. In no
way does this violate the
integrity of transaction or compromise the integrity of the repository.
It can be implemented in
a way that is completely transparent to the user and is literally a
no-op when the transaction
goes un-modified.
bw
Philip Martin wrote:
>Brett Wooldridge <br...@riseup.com> writes:
>
>
>>Would it be possible for the server to pass the new checksum back to
>>the client in the commit-response?
>>
>>
>
>Just about anything is possible if someone is prepared to design and
>implement it. Are you proposing that the file I commit gets modified
>by the repository and then my working copy version of the file gets
>changed to match that in the repository? That would mean that the
>exact version of the the file I committed (the one I tested) gets
>lost. Will your pre-commit run build and regression tests with the
>modified file to verify that the changes are sensible? I guess that
>might be academic, if your developers cannot format files correctly
>they probably can't write regression tests.
>
>I can see that the idea of modifying the txn in pre-commit is
>attractive, I have yet to see an example where I would want it to
>occur in practice. I suppose it might work for something like
>automatically modifying a file not otherwise involved in the
>transaction, accumulating log messages in a Changelog file perhaps.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Philip Martin <ph...@codematters.co.uk>.
Brett Wooldridge <br...@riseup.com> writes:
> Would it be possible for the server to pass the new checksum back to
> the client in the commit-response?
Just about anything is possible if someone is prepared to design and
implement it. Are you proposing that the file I commit gets modified
by the repository and then my working copy version of the file gets
changed to match that in the repository? That would mean that the
exact version of the the file I committed (the one I tested) gets
lost. Will your pre-commit run build and regression tests with the
modified file to verify that the changes are sensible? I guess that
might be academic, if your developers cannot format files correctly
they probably can't write regression tests.
I can see that the idea of modifying the txn in pre-commit is
attractive, I have yet to see an example where I would want it to
occur in practice. I suppose it might work for something like
automatically modifying a file not otherwise involved in the
transaction, accumulating log messages in a Changelog file perhaps.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Pre-commit transaction modification question
Posted by Mark <ma...@msdhub.com>.
If my opinion as the administrator of several repositories in my
organization mattered, I'd be +1 on this. Seems like it's a good idea even
if the txn isn't being modified, just for safety's sake.
Mark
-----Original Message-----
From: Brett Wooldridge [mailto:brettw@riseup.com]
Sent: Wednesday, February 11, 2004 9:38 PM
To: Philip Martin
Cc: simon@ecnetwork.co.nz; users@subversion.tigris.org
Subject: Re: Pre-commit transaction modification question
Would it be possible for the server to pass the new checksum back to the
client
in the commit-response? WebDav is request/response, right? So, when the
client recieves the commit response, it compares C' with C. 100% of the
time
with a non-modifying commit hook, C' will match C. In the case where they
do not match (i.e. with a hook that augmented F), the client could
refresh it's
copy from the repository. This seems like it would be a sound validation
regardless of permitting a pre-commit hook to augment the file. There is no
transaction violation by the pre-commit hook, as the transaction is
still open.
There is no corruption of the repository possible, merely a client
synchronization
issue to resolve.
If you wanted a zero impact model in the nominal case, C' doesn't even need
to get sent in the reply if C and C' do not differ. It's presence would
indicate
that a difference was detected.
bw
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Brett Wooldridge <br...@riseup.com>.
Would it be possible for the server to pass the new checksum back to the
client
in the commit-response? WebDav is request/response, right? So, when the
client recieves the commit response, it compares C' with C. 100% of the
time
with a non-modifying commit hook, C' will match C. In the case where they
do not match (i.e. with a hook that augmented F), the client could
refresh it's
copy from the repository. This seems like it would be a sound validation
regardless of permitting a pre-commit hook to augment the file. There is no
transaction violation by the pre-commit hook, as the transaction is
still open.
There is no corruption of the repository possible, merely a client
synchronization
issue to resolve.
If you wanted a zero impact model in the nominal case, C' doesn't even need
to get sent in the reply if C and C' do not differ. It's presence would
indicate
that a difference was detected.
bw
Philip Martin wrote:
>Brett Wooldridge <br...@riseup.com> writes:
>
>
>
>>Anyway, regardless of the diff issue, it seems like update could
>>certainly send an MD5 hash along with the version.
>>
>>
>
>The client doesn't send a checksum during update, however the
>repository does send one in it's response when the update modifies a
>file.
>
>Here's how it works
>
> - client commits file F with the text T and checksum C
> - pre-commit modifes the text of F to T' with checksum C'
> - client assumes T and C represent F at the new revision R and so
> the wc is corrupt
>
>What happens next?
>
>Possibility one
> - file F in the repository is still at revision R
> - client runs update for F
> - client's revision R matches repository's revision R so no
> checksums are exchanged
> - there is no indication that the wc is corrupt
>
>Possibility two
> - file F in repository has been modified to revision R' by some
> other commit
> - client runs update for F
> - checksum C' from repository for revision R doesn't match checksum
> C stored in the wc
> - update fails with checksum error
>
>Possibility three
> - file F in repository is still at revision R
> - F in the corrupt wc has been modifed from T
> - client commits F
> - checksum C from client for revision R doesn't match checksum C'
> stored in the repository
> - commit fails with checksum error
>
>If you *really* want to modify text in the pre-commit you could hack
>the client so that it doesn't carry out the post-commit client-side
>processing, that's when the working copy gets corrupted. Doing that
>would mean that the committed items would continue to show up as
>locally modifed after the commit, but any attempt to commit then again
>would fail with an "out of date" error. The user would then have to
>run update and that would retrieve the the new revision as modifed by
>the pre-commit and attempt to merge it into the working copy. The
>merge would either succeed or leave local conflicts, but either way
>the working copy would not be corrupt.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Philip Martin <ph...@codematters.co.uk>.
Brett Wooldridge <br...@riseup.com> writes:
> Anyway, regardless of the diff issue, it seems like update could
> certainly send an MD5 hash along with the version.
The client doesn't send a checksum during update, however the
repository does send one in it's response when the update modifies a
file.
Here's how it works
- client commits file F with the text T and checksum C
- pre-commit modifes the text of F to T' with checksum C'
- client assumes T and C represent F at the new revision R and so
the wc is corrupt
What happens next?
Possibility one
- file F in the repository is still at revision R
- client runs update for F
- client's revision R matches repository's revision R so no
checksums are exchanged
- there is no indication that the wc is corrupt
Possibility two
- file F in repository has been modified to revision R' by some
other commit
- client runs update for F
- checksum C' from repository for revision R doesn't match checksum
C stored in the wc
- update fails with checksum error
Possibility three
- file F in repository is still at revision R
- F in the corrupt wc has been modifed from T
- client commits F
- checksum C from client for revision R doesn't match checksum C'
stored in the repository
- commit fails with checksum error
If you *really* want to modify text in the pre-commit you could hack
the client so that it doesn't carry out the post-commit client-side
processing, that's when the working copy gets corrupted. Doing that
would mean that the committed items would continue to show up as
locally modifed after the commit, but any attempt to commit then again
would fail with an "out of date" error. The user would then have to
run update and that would retrieve the the new revision as modifed by
the pre-commit and attempt to merge it into the working copy. The
merge would either succeed or leave local conflicts, but either way
the working copy would not be corrupt.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-02-11 at 19:48, Brett Wooldridge wrote:
> I have to agree with you. The checksum (or MD5 hash) method was going
> to be my
> suggested solution. Additionally, it seems like running a 'diff' off of
> a local cached copy
> is possibly frought with issues of it's own. What if the file has
> changed dramatically on
> the server through another commit? My diff isn't going to show that?
No, it just means you need to give the proper arguments to 'svn diff'.
With no arguments, it only prints local mods (no network access). It
also has modes where it compares local vs. repository, or repository vs.
repository. I'm starting to think you've never used svn. ;-)
>
> Anyway, regardless of the diff issue, it seems like update could
> certainly send an MD5 hash
> along with the version. In fact, I'll be glad to implement it, if it
> would be welcome.
Actually, Philip is right. I forgot about the checksum feature. SVN
client and server *do* use checksums when passing binary diffs in either
direction over the network. They always pass a 'result' checksum ("what
the file should be after the diff is applied"), and often pass a 'base'
checksum as well ("the file you should be patching").
So my earlier statements about corruption aren't entirely true: you'll
just get zillions of failed updates and commits -- all errors about
checksum mismatches.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by "C. Michael Pilato" <cm...@collab.net>.
Brett Wooldridge <br...@riseup.com> writes:
> Anyway, regardless of the diff issue, it seems like update could
> certainly send an MD5 hash along with the version. In fact, I'll be
> glad to implement it, if it would be welcome.
I would not welcome it. Our update reports are designed to be
concise. If you have revision 5 of a big ol' tree except for a couple
of files at revision 6, your update report says "I have revision 5 of
this whole tree except for these couple of files at revision 6."
I do NOT want to see that update report turn into "I have revision 5
of this whole tree except for these couple of files at revision 6.
Oh, and by the way, here are the MD5 checksums of everything in my
working. Enjoy!"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Brett Wooldridge <br...@riseup.com>.
Simon Kitching wrote:
>On Thu, 2004-02-12 at 12:57, Ben Collins-Sussman wrote:
>
>
>>On Wed, 2004-02-11 at 17:48, Brett Wooldridge wrote:
>>
>>
>>
>>>CVS has the same 'issue', in that after checking in the source, the
>>>source in the repository nolonger matches the source on the user's
>>>system [...] the only side-effect being that an immediate diff will
>>>show the differences in formatting, but after an 'update', the work is
>>>right again.
>>>
>>>
>>That won't work in Subversion. Honest. 'svn diff' is not a network
>>operation: it compares the working file with the cached copy in .svn/.
>>
>>It's worse than that: when you run 'svn up', the client says: "I have
>>version N of foo.c".
>>
>>
>
>Just in theory, the client could say "I have version N of foo.c, with
>checksum xxxxx". The server is then able to detect this and return a
>corrected file. The .svn/Entries file already holds a checksum for each
>base file, doesn't it?
>
>Not that I'm asking for a new feature - just pondering.
>
>
I have to agree with you. The checksum (or MD5 hash) method was going
to be my
suggested solution. Additionally, it seems like running a 'diff' off of
a local cached copy
is possibly frought with issues of it's own. What if the file has
changed dramatically on
the server through another commit? My diff isn't going to show that?
Anyway, regardless of the diff issue, it seems like update could
certainly send an MD5 hash
along with the version. In fact, I'll be glad to implement it, if it
would be welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> There is no checksum for versioned properties, so if the post-commit
s/post/pre/
> hook modifies those the working copy corruption will not be detected.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Philip Martin <ph...@codematters.co.uk>.
Simon Kitching <si...@ecnetwork.co.nz> writes:
> Have I misunderstood?
If you use a pre-commit hook that modifes files in the txn then those
files in the working copy will become "corrupt" as they will not have
the text or checksum committed. Any attempt to commit or update the
corrupt files will fail and a checksum error will be reported. The
rest of the working copy will function correctly.
There is no checksum for versioned properties, so if the post-commit
hook modifies those the working copy corruption will not be detected.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Thu, 2004-02-12 at 12:57, Ben Collins-Sussman wrote:
> On Wed, 2004-02-11 at 17:48, Brett Wooldridge wrote:
>
> > CVS has the same 'issue', in that after checking in the source, the
> > source in the repository nolonger matches the source on the user's
> > system [...] the only side-effect being that an immediate diff will
> > show the differences in formatting, but after an 'update', the work is
> > right again.
>
> That won't work in Subversion. Honest. 'svn diff' is not a network
> operation: it compares the working file with the cached copy in .svn/.
>
> It's worse than that: when you run 'svn up', the client says: "I have
> version N of foo.c".
Just in theory, the client could say "I have version N of foo.c, with
checksum xxxxx". The server is then able to detect this and return a
corrected file. The .svn/Entries file already holds a checksum for each
base file, doesn't it?
Not that I'm asking for a new feature - just pondering.
> The server then says, "OK, I have nothing to send
> you, then." Of course, the working copy and repository completely
> disagree on what "version N of foo.c" means, but they're not aware of
> that. You'll never get the diff from the server, and thus never get a
> copy of what's really in the repository.
>
> It's even worse than that: when you change foo.c again and try to
> commit, your client is going to send binary diffs to the server (again,
> by comparing the working file with the cached .svn copy). The server is
> then going to try and apply these binary diffs to a file that has
> DIFFERENT CONTENT.
From my lurking on subversion lists, I thought that scv commit etc. sent
a checksum of the base as well as a diff to prevent this sort of
situation. Have I misunderstood?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-02-11 at 17:48, Brett Wooldridge wrote:
> CVS has the same 'issue', in that after checking in the source, the
> source in the repository nolonger matches the source on the user's
> system [...] the only side-effect being that an immediate diff will
> show the differences in formatting, but after an 'update', the work is
> right again.
That won't work in Subversion. Honest. 'svn diff' is not a network
operation: it compares the working file with the cached copy in .svn/.
It's worse than that: when you run 'svn up', the client says: "I have
version N of foo.c". The server then says, "OK, I have nothing to send
you, then." Of course, the working copy and repository completely
disagree on what "version N of foo.c" means, but they're not aware of
that. You'll never get the diff from the server, and thus never get a
copy of what's really in the repository.
It's even worse than that: when you change foo.c again and try to
commit, your client is going to send binary diffs to the server (again,
by comparing the working file with the cached .svn copy). The server is
then going to try and apply these binary diffs to a file that has
DIFFERENT CONTENT. Most likely, the binary diff application will
completely fail. And if it doesn't, you'll have a totally corrupted,
mangled repository file.
So I'm not being paternalistic here: there is *no* way to do what you
want with Subversion. All roads lead to data corruption. The only
possible solution I can imagine is that every employee destroy their
working copy after *every* commit they do, and checkout a new one.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Brett Wooldridge <br...@riseup.com>.
Ok, arguments about merits aside (as we've been using this model under
CVS for over a
year without issue) -- I'd still like to know how to accomplish this
under Subversion. CVS
has the same 'issue', in that after checking in the source, the source
in the repository no
longer matches the source on the user's system. Again, for our
organization, this has not
been an issue -- the only side-effect being that an immediate diff will
show the differences
in formatting, but after an 'update', the work is right again. So,
paternalism aside, can you
please help me shoot myself in the foot? :-)
bw
Ben Collins-Sussman wrote:
>On Wed, 2004-02-11 at 17:18, Brett Wooldridge wrote:
>
>
>>Any help, pointers, and advice is appreciated.
>>
>>
>
>DON'T DO IT.
>
>If the repository mangles the files as they enter the repository, then
>your working copy will be completely wrong. The working copy will
>think, "ah, this file I committed is what the latest version looks
>like", but in reality, the latest version in the repository is very
>different. There's no way for the pre-commit hook to tell the working
>copy that it mangled the data.
>
>What Subversion people have done instead is to install a pre-commit hook
>which merely *validates* a style, and rejects the whole commit if any
>file files to conform. This forces users to run the reformatter.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pre-commit transaction modification question
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-02-11 at 17:18, Brett Wooldridge wrote:
> Any help, pointers, and advice is appreciated.
DON'T DO IT.
If the repository mangles the files as they enter the repository, then
your working copy will be completely wrong. The working copy will
think, "ah, this file I committed is what the latest version looks
like", but in reality, the latest version in the repository is very
different. There's no way for the pre-commit hook to tell the working
copy that it mangled the data.
What Subversion people have done instead is to install a pre-commit hook
which merely *validates* a style, and rejects the whole commit if any
file files to conform. This forces users to run the reformatter.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org