]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/bugs/svn_fails_to_update.mdwn
web commit from 82.236.189.224: poll vote (It's fast enough)
[git.ikiwiki.info.git] / doc / bugs / svn_fails_to_update.mdwn
index fda003a4419f6823f5c7e82bcec8e54392e1a0d6..6ed839cf6d52138ee497cd7e9318a30c64f17e99 100644 (file)
@@ -70,4 +70,20 @@ 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
\ No newline at end of file
+--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]]