On 23.05.2014 17:30, Ben Fritz wrote:
> On Thu, May 22, 2014 at 12:36 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>> On 20.05.2014 23:26, Ben Fritz wrote:
>>> I know that these peg revisions will technically give me the same file
>>> content. But I can't just commit changes willy-nilly to the externals
>>> definitions every time I check. And determining that an external has
>>> not actually been changed after such a commit would require an extra
>>> several steps to view the history of the folder or file in question to
>>> figure out that the two revisions are actually identical.
>>
>> Or:
>> set the peg revision as it is done now, run update.
>> If you see any changes in the dialog that shows the update progress, use
>> that new revision.
>> If not, revert the property change.
>>
>
> So you're saying, set the peg to the latest for ~40 external rules,
> then do an update and individually revert those rules with no changes?
> No, thanks.
>
> What I do now:
> 1. Double-click the rule
> 2. Click "show log"
> 3. The log pops up and automatically selects the latest version
> 4. Click OK
> 5. Repeat steps 1-4 for each of ~40 externals
>
> I'd really like to be able to hit "find HEAD" once, then individually
> update only the changed rules.
>
Wow, 40 externals, that's quite a lot.
I see your problem here though, with that many externals it's really not
an option.
>>> Is there some use-case that requires the last committed version
>>> anywhere in the repository? Or can this be changed to pull in the last
>>> change revision instead? As the feature stands right now, it is pretty
>>> much useless for the purpose of checking for updates on all the
>>> externals at once, and automatically updating to the minimum required
>>> version for each rule.
>>
>> To get the "last changed revision" we would have to fetch the log for
>> the folder, not just ask the repo for the HEAD revision. That would take
>> a lot longer.
>>
>
> Why can't you just do the equivalent of "svn info /path/to/external"
> and extract the last changed revision from there?
'svn info' does not return the correct revision if the server is (I
think) older than 1.5. Or maybe the server has to be even older for, but
I know that an early version only returned the 'last committed revision'
of a folder where the folder itself was changed, not the last revision
any subitem was changed.
Of course, I could just use 'svn info' and then tell users to update
their server if it doesn't work - might not be so bad because those old
versions are not supported anymore (i.e., don't get security updates).
> I'm almost tempted to write a script to do that for me but that's WAY
> less convenient than the button in the dialog that *almost* does what
> I want.
>
> What's the use case for it acting the way it does now? I can't
> actually see how the information it gives right now is useful in any
> way.
Well, it works very well as it is. I don't think there are many people
who care that the pegged revision is actually the 'last committed' one
instead of HEAD, because the result is the same: you get the same code
when you check out or update.
I'll do some testing using 'svn info'. Not sure yet if I'm going to add
an option for this or just force users to update their server - but I'm
going to use 'svn info' so you get the result you want.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3079046
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-05-23 20:34:22 CEST