X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/2f6e3459d17ec4f6c107472f910a2ba5f7171f50..8a8277faf8a084694745cfd20906733df46b4ff9:/doc/bugs/svn_fails_to_update.mdwn diff --git a/doc/bugs/svn_fails_to_update.mdwn b/doc/bugs/svn_fails_to_update.mdwn index 1597ce6bc..6ed839cf6 100644 --- a/doc/bugs/svn_fails_to_update.mdwn +++ b/doc/bugs/svn_fails_to_update.mdwn @@ -51,3 +51,39 @@ but *does* happen when committing from the web. >>> You say that the rcs information for web commits is screwed up .. how? >>> Does this affect something that I'm not seeing? --[[Joey]] + +I just meant that when you call ikiwiki.cgi?do=edit, it gets the +"current" RCS revision, and uses that in the merges later if there +are other edits in the meantime. So I guess if you have a file a.mdwn, +and at revision X it contains the list: + + a + b + c + d + +And then one user edits it by removing "c" from web, and +then starts editing it again, ikiwiki.cgi will think the edit "started" +at revision X (although it's really X+1). So if another user edits via +web in the meantime, the subsequent merge will try to remove "c" again. +To be honest I don't know what will happen in this case (svn merge fails? +conflict markers?), but I'm pretty sure it's a problem. Anyhow, I think we +should call update manually after commit, I just don't know if this should +be RCS-specific, or whether it's safe to update after commit on all RCSes. +--Ethan + +Hmm, turns out that isn't the case! svn's prepedit function calls svn info +which gets the "right" information even when the WC isn't current. I am +having problems merging but that probably has nothing to do with this bug. +[This patch](http://ikidev.betacantrips.com/patches/update.patch) calls +rcs_update after commit in CGI.pm, it might be a good idea anyhow. --Ethan + +> Ok, I follow you. I am unsure whether this problem effects other rcses +> besides svn. Depends on how they handle locking, etc. But calling +> rcs_update will always be safe, so I'll do that. [[bugs/done]] +> +> That still leaves the issue that it calls svn update in the post-commit +> hook when it's locked and fails with that error message. Granted svn does +> throw that away by default, but it's still ugly and wasteful. But +> checking for a lock first is even uglier (and racey) and more wasteful, +> so I don't see a fix.. --[[Joey]]