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 <markphip_at_gmail.com> wrote:
> 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.
Received on 2015-08-26 17:07:10 CEST