By no means a svn expert, I am wondering in what scenarios would you not want to svn update immediately after performing a svn commit, assuming* you are committing everything in your working copy. Any practical examples/scenarios?
In other words, why shouldn't everyone using SVN have an alias/function in place such as svn commit && svn update? (disregarding commit's -m flag)
* I cite this assumption because I think it's generally supported to be a best practice when developing under version control, although there are of course occasional times to cut corners on this and I suspect that's the primary answer to my question.
Right. Perhaps it's worth clarifying that all updating (including resolving any conflicts), re-building, and testing has been performed so now you're ready to really commit. That's the starting point for my question.
I can't think up a case when you should not or must not run svn update after running svn commit. Assuming that all the stuff quoted above has been performed, why not to do an svn update? At the same time, why would you want to run svn update?
Run svn update the next time you start working on the task, the next time you see commits in the feature branch you are working on (or any other branch or trunk that you are workin on at that moment) and make sure to run svn update before you commit your changes.
The main rule here is to run svn update often to ensure that there are no conflicts with your work and the work of others (assuming you modify the same files).
Read SVNBook:
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments