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.
Received on 2011-01-06 16:18:50 CET