Hi Mark. No, the issue is about when head is r5678 and I request "svn update -r100" then I want the externals to be updated to r100 not to r5678.
- Julian On 26 August 2015 at 15:48, Mark Phippard <markp...@gmail.com> wrote: > On Wed, Aug 26, 2015 at 10:42 AM, Julian Foad <julianf...@btopenworld.com> > wrote: >> >> Mark Phippard wrote: >> > Julian Foad wrote: >> >> Jörg Rebenstorf wrote: >> >> [...] >> >> > The new access option should update the working copy of the primary >> >> > target "PATH..." and its externals to a certain inter-repository >> >> > consistent state, that is, to update the primary target and all of >> >> > its >> >> > externals content to their appropriate version at a certain point in >> >> > time. >> >> > The new access method shall be an additional command-line option, for >> >> > example "--sync-externals", for the svn client tool's update command >> >> > like: >> > >> > Why do we even need to introduce a new option here? What would be >> > controversial about just doing this automatically (for externals from >> > the >> > same repository that do not specify a revision in the external)? >> > >> > Isn't this just the expected and desired behavior? >> >> Hi, Mark. >> >> I don't think we can claim that the existing behaviour has been >> obviously and totally wrong all along, and just change it. It gave >> logical and predictable results, just not the results we think most >> people would expect or want. People will have got used to it, and >> while it's easy to imagine many cases where that's not desired, I can >> also imagine there are many cases where that's now being relied on. > > > Maybe I misunderstand the real issue because the issue tracker and this > thread are focusing more on syntax solutions and assuming the problem is > understood. > > Isn't this ultimately about race condition type scenarios? I run svn up on > my WC. It updates it to r100 and then moves on to the externals. In the > meantime, more commits happened in my repository and so the externals from > the same repository actually update to r102. > > I find it hard to believe people have come to rely on this and want it. The > results are "understandable", but not "logical and predictable". > > Likewise, if I specified svn up -r100 it again seems more "logical and > predictable" if it did the same to my externals. They could, after all, > have -r HEAD added to them if this was not desired. > >> >> >> When something we designed clearly could never have been useful, then >> we can call it a bug and change it, but that's not the case here. > > > I think it is a bug because someone could always explicitly add -r HEAD or > @HEAD to the external to get that behavior. > > > That said, this is total drive-by feedback. I might not have taken enough > time to really understand the issue here.
