On Wed, Aug 26, 2015 at 10:42 AM, Julian Foad <julianfoad_at_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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2015-08-26 16:48:30 CEST