svn status (or just svn st) is the easiest way of checking your local workspace against trunk).
Dan Sent from my iPhone On 28 Oct 2010, at 10:15, "Kevin Meyer" <[email protected]> wrote: > >>> On Thu, October 28, 2010 00:41, Dan Haywood wrote: >>>> It doesn't look like you've done a full svn update? >>> >>> That's a question - My first svn update got interrupted (link forcibly >>> closed by host). The second update fetched more files. The third says >>> update complete. >>> >>> How error prone is svn when links are forcibly closed? I thought it was >>> supposed to be atomic. >>> >> >> Commits are atomic, but doing an svn update isn't, as you've seen. > > See below.. > >>> >>> If I do have an unstable svn state, what can repair it? >> >> Not sure what you mean by "unstable svn state"; an interrupted svn update >> is not serious, just try again. >> > > This is just the problem - you're suggesting that I don't have a fully > up-to-date update. But I repeatedly performed updates until the dialog > stated that I was up-to-date. So, I believe, it would be reasonable to > expect that I am fully synchronized. Therefore, any issues that I am > now experiencing are either caused by my svn state being unstable (i.e. > not a reliable mirror of the server) or uncommitted differences > from source (i.e. you have not comitted all changes). A third option is > that somehow your build environment is solving dependencies that mine > isn't. > > I guess one of my questions is: Can I somehow compute (for example) an > md5 checksum of all sources and compare it against a server value? > If done on a per-module basis, then I can at least determine which > modules of mine are not properly synchronised with the server? > > FYI: I am building from command line. > >
