"Mark Phippard" <markphip_at_gmail.com> writes:
> On Sat, May 31, 2008 at 7:41 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>> There's no doubt this is a nasty bug, and obviously, the fix should be
>> backported to 1.5.1 at least. But does it justify an RC9? I'm not so
>> sure. It's not exactly "corruption"... more like "misleading the user"
>> or some lesser misdemeanor.
>
> Thanks for the analysis and explanation. I could probably be swayed
> either way on this one, but based on what you discovered and posted
> here I am inclined to agree with you that this might not be worth
> doing a new RC for. BTW, one thing I was not clear on in your
> analysis, is whether the fix that glasser and cmpilato proposed for
> backport has fixed the problem or not. It kind of sounds like there
> is more to do?
Sorry, I didn't explain that part very clearly.
The fix committed on trunk (r31516) solves the problem, in that it
leaves no known way for a user to get into this situation. However,
r31516 may mask a latent problem that could bite us later: the 1.4.x
repository ought to reject the commit in the first place, given that the
client [should have] reported r1 yet the file had changed since r1.
The potential for latent problems is on both the client side and the
server side: during commit, the client may be reporting base revisions
in a wrong way, and/or the server may be interpreting them in a wrong
way. None of that code was affected by r31516, so if those (potential)
bugs were there before, they're still there.
That's the question I'm going to look into tomorrow.
However, r31516 is still good, and solves the immediate problem: it
modifies the depth filter around the update editor so that we don't get
into this situation in the first place.
> Anyway, clearly there is a bug and clearly it needs to be fixed. I am
> not sure if this qualifies are corruption or not. If it does, it is
> at least on the mild end of the spectrum. I like to think of it in
> other ways. If this bug existed in our official releases how quickly
> would we push out a new .x release. I kind of do not see us rushing
> one out the door over this. I think we would certainly start alerting
> people that we need to create a .x release but I think we would let it
> evolve and come out somewhat normally. The other criteria would be
> whether we would backport this to several of our previous releases.
> Again, I'd be surprised if we would backport this to 1.3, 1.2 etc.
> based on what you have described above.
Right. These are theoretical considerations, since those releases
didn't have the --depth flag anyway, but I see your point.
> So based on that, I'd be inclined to say we could put this in a 1.5.1.
I think I agree. But, I'd like to hear what others (specifically,
glasser and cmpilato) have to say. In particular, if there's some way
this can be used to cause truly corrupt data to go into the repository
-- that is, where the final file content in the repository does not
match the content of the working file that was committed -- then that
would be a showstopper.
So far, I don't see a way to make that happen, but this deserves more
brains. Mmmm. Brains.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-01 05:12:07 CEST