问题
I want to ask if somebody heard about a SVN monitoring tool for this case: in the past we used MS SourceSafe with checkout & lock mechanism to avoid merges. One benefit of this was the "release manager" can see in the repo whitch files are still not checked in. SVN is a great tool, but sometimes I miss this information, even to avoid big conflicts. Is there a monitoring system which can be used to see who has changed files pending for commiting? On every workstation a service/daemon collecting the modification information, sendig it periodcally to a central server and client apps to see the information.
It is only a idea, I don't know i fit would make sense...
Kind regards, Andi
回答1:
svn does not require locks on checkouts; however, it supports locks. So, if your teams is more comfortable with this style of working, I suggest that you use the svn locking feature.
Basically, you have more flexibility than before:
If a developer just wants to "try something", he can update his working copy and modify the file without locking it.
If a developer wants to work on a file exclusively (to avoid merges), he can update his working copy, lock the file, work on it, and, when he's done, commit the change and unlock the file.
回答2:
Since you were referring to MS SourceSafe I realize you might be in the MS world, but just in case you're not. If you're doing Java, Ruby, PHP, Javascript, Android, Flex work I'd recommend switching to IntelliJ IDE because it has a great view for SVN history built right into your IDE. You can see every check in (Repository tab), and the files changed in that check in (on the right hand side). I included a screen shot just is case. Really easy so you can just get to diffin' and cursing.
回答3:
I don't think this can really help for these circumstances though. In my opinion, a release is ready when all its features are complete, and tested. When I have a dirty file in my working copy because I was trying to refactor something, or testing something, that's not a reason to keep the release. The information given by the release manager can't help you determine wether the release is done or not.
As for checking for conflicts, the only way to check for that is to monitor the repository. Again, not all dirty files I have locally will be committed.
回答4:
If all the developers do feature development in separate branches, it is easy to see in the SVN repo browser what everyone is working on before code is merged back to trunk. This approach has the added benefit over the proposed approach, that the developers get to signify which "pending" changes they are working on are meaningful (i.e. what is committed to the branch) and which changes are just scratch work (which you won't see in the repo browser).
If you want a truly at glance view of conflicts in pending trunk merges, it is conceivable that you could create a script that tries to merge all the pairs of feature branches back to trunk. You could then graph a table that shows which combinations of branches merge successfully and which ones failed to merge. Either update the graph on a website in the post-commit hook, or schedule it as a batch job once a day to send out in an email to the developers. Should be much quicker to implement than a file-monitoring scheme reporting back to a centralized server.
来源：https://stackoverflow.com/questions/3779117/idea-svn-monitor-for-pending-commits