Afternoon, Following a spate of high-profile subversion problems at my $client, we've decided to implement both client and server "sanity" hooks, which we're hoping will prevent most of the problems from happening again.
I'm working on the client part at the moment, which will take the form of tortoisesvn hooks. Before I spend too much time on it I wanted to get some opinions from the experts, in case I'm going off in the wrong direction. The client side will just warn users about potential issues and prod them in the right direction, given that it would be trivial to bypass the client hooks anyway, eg by using cmd line. Most of the user angst has been generated by doing cherry-picking... eg, dealing with tree conflicts, the "Attempt to add tree conflict that already exists" http://svn.haxx.se/dev/archive-2010-11/0295.shtml bug , having to resolve conflicts multiple times when merging broken ranges, http://svn.haxx.se/users/archive-2010-11/0442.shtml losing data through merging into a conflicted file etc. The client tool will simply 1) warn that there are revs with lower numbers than the one they have actually merged which are eligible for merge. I think often when people (here) cherry pick they don't realise that's what they're doing, they just merge the revs they think they need. It will also, using a differencing algo, try to match unversioned/added files with missing/removed files, and 2) warn that a rename has been done outside of subversion. At this stage it just recommends the user to fix them using tsvn's useful but rather well-hidden feature to handle this. (Aside: could this be more prominent in tsvn? TortoiseHg has this feature built-in). We see this happen mostly through use of IDE plugins which are not aware that a VCS is in use. Next, it looks for files that are unversioned or added, when they should have been added with history. This happens when a user does a merge where new files are added, reverts all (which resurrects deleted files, undoes mods, but contrary to all intuition leaves added files as unversioned files), then does the merge again. This check 3) looks at the revisions that have been merged, looks for added files in each ones, and verifies that files with the same names don't exist as unversioned files in the WC. Aside: Could tsvn treat "skipped files" as at least a serious problem as conflicts? These are easily missed. Even if they're noticed by the user, "skipped files" sounds benign, like they'll just be merged across next time someone does a merge, except they totally won't, and will lead to tree conflicts in future merges. Finally it 4) looks for subtree merge info and warns users to do a merge from the branch root. Whilst this is supposed to not be a problem, in practice we've seen a lot of issues caused by this. I was working on 5) trying to ensure branches and tags are made from clean, non-mixed working copies, but as these tend to be done WC->URL the tsvn hook can't catch this, so it will have to be done server-side. Anyway, grateful for any advice on any of these checks. jamie -- View this message in context: http://old.nabble.com/subversion-client-hooks---any-advice--tp30605816p30605816.html Sent from the Subversion Users mailing list archive at Nabble.com.
