>> Ironically this proposition would make some Monticello operations
>> slower, because Monticello will need to download and open all versions
>> with the same name to figure out if the ancestry matches.
>>
>> Furthermore, this would subtly break many tools, because most of them
>> do not look at t
Lukas,
On 30 Jan 2012, at 06:53, Lukas Renggli wrote:
> Ironically this proposition would make some Monticello operations
> slower, because Monticello will need to download and open all versions
> with the same name to figure out if the ancestry matches.
>
> Furthermore, this would subtly break
>> Would it not be possible to assign the version name based on local, best
>> effort knowledge alone and deal with possible conflicts afterwards (there is
>> the ancestory) ?
>
> to me that would make more sense.
>
> - Is it necessary that the version name is globally unique? I doubt so.
> - Hav
Last week I noticed the same behavior... not really such a big fan of it
On 2012-01-29, at 20:05, Sven Van Caekenberghe wrote:
> Today I pressed Command-. while looking at a slow Monticello save, I was
> wondering what the system was doing before I even had written my commit
> message.
>
> App
Today I pressed Command-. while looking at a slow Monticello save, I was
wondering what the system was doing before I even had written my commit message.
Apparently, MCWorkingCopy>>#uniqueVersionName checks every repository linked to
the package, (6 for Zn in my case), to see if the proposed ver
