[Pharo-project] MCWorkingCopy>>#uniqueVersionName
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 version name is unique across all these repositories, not using the cache. I understand this, but this comes down to 6 times getting the list of all package names from remote servers. One way to speed this up would be to parallelize these. But fundamentally, I thought Monticello was supposed to be a distributed version control system ? 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) ? Just thinking out loud. Sven
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.
Apparently, MCWorkingCopy>>#uniqueVersionName checks every repository linked to the package, (6 for Zn in my case), to see if the proposed version name is unique across all these repositories, not using the cache.
I understand this, but this comes down to 6 times getting the list of all package names from remote servers.
One way to speed this up would be to parallelize these.
I guess that could be done with very little effort.
But fundamentally, I thought Monticello was supposed to be a distributed version control system ?
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. - Having it unique per repository should be enough, no?
Just thinking out loud.
Sven
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. - Having it unique per repository should be enough, no?
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 the ancestry but only at the filename (again to make it fast). Last but not least, the proposal will annoy people that want to integrate changes and that cannot because a file with that name is already in their repository. Lukas -- Lukas Renggli www.lukas-renggli.ch
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 many tools, because most of them do not look at the ancestry but only at the filename (again to make it fast).
Last but not least, the proposal will annoy people that want to integrate changes and that cannot because a file with that name is already in their repository.
Can we then do nothing at all ? What about changing the naming, like adding an extra UUID to the name ? Don't _you_ have any ideas about speeding up Monticello ? Thx, Sven
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 the ancestry but only at the filename (again to make it fast).
Last but not least, the proposal will annoy people that want to integrate changes and that cannot because a file with that name is already in their repository.
Can we then do nothing at all ?
Commit speed has never been a problem to me.
What about changing the naming, like adding an extra UUID to the name ?
That would have been a solution before all tools started to depend on the naming.
Don't _you_ have any ideas about speeding up Monticello ?
Use Monticello 2 that addresses this and many other problems of Monticello 1. But then people also criticize Monticello 2 because it addresses this problem, and version data is not human readable anymore. Lukas -- Lukas Renggli www.lukas-renggli.ch
participants (3)
-
Camillo Bruni -
Lukas Renggli -
Sven Van Caekenberghe