Version number difference between MC and GitFileTree
Hi Thierry, When I commit from MC, I see the generated commit, with something like OSSubprocess-MarianoMartinezPeck.7. However, when browse the repository later from MC, I get that such a commit is displayed as OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message maps correctly). Could this offset be because of the first initial 3 commits? That is, initial git commit from github, and 2 commits of "gitfiletree repository properties". Is there a workaround here so that both could map correctly? Thanks in advance, -- Mariano http://marianopeck.wordpress.com
Yes, there is a version number mismatch. But I do not feel this is that important. On some point, version number should be extracted from Git metadata, and not from a simple counter. By the way, what is a âsubprocessâ? Alexandre
On Jan 3, 2016, at 1:04 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi Thierry,
When I commit from MC, I see the generated commit, with something like OSSubprocess-MarianoMartinezPeck.7. However, when browse the repository later from MC, I get that such a commit is displayed as OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message maps correctly).
Could this offset be because of the first initial 3 commits? That is, initial git commit from github, and 2 commits of "gitfiletree repository properties".
Is there a workaround here so that both could map correctly?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Le 03/01/2016 17:12, Alexandre Bergel a écrit :
Yes, there is a version number mismatch. But I do not feel this is that important. On some point, version number should be extracted from Git metadata, and not from a simple counter.
I'm solving that (forcing a become to replace the MC version info by the new git generated version info... but the GUI isn't updated). If someone is interested to have a look at refactoring the underlying Monticello model of versions and repositories and caches and ... ;) Thierry
By the way, what is a âsubprocessâ?
Alexandre
On Jan 3, 2016, at 1:04 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi Thierry,
When I commit from MC, I see the generated commit, with something like OSSubprocess-MarianoMartinezPeck.7. However, when browse the repository later from MC, I get that such a commit is displayed as OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message maps correctly).
Could this offset be because of the first initial 3 commits? That is, initial git commit from github, and 2 commits of "gitfiletree repository properties".
Is there a workaround here so that both could map correctly?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
On Sun, Jan 3, 2016 at 1:12 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Yes, there is a version number mismatch. But I do not feel this is that important. On some point, version number should be extracted from Git metadata, and not from a simple counter.
Well, I does confuses me, because the idea of GitFileTree is to integrate git into the image. So if I browse with MC and that does not match at all what I committed via MC itself too, then that is confusing. At least for me. For that a case, I would prefer to commit , push, pull etc everything by hand and that would be clearer.
By the way, what is a âsubprocessâ?
It's name I gave to the project I started (the one I send the survey), it's called (at least so far) OSSubprocess. This is easy because one can think it's quite close to OSProcess (which is true). It seems Python does have similar names: https://docs.python.org/2/library/subprocess.html If you have a better name I am all ears :) Alexandre
On Jan 3, 2016, at 1:04 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi Thierry,
When I commit from MC, I see the generated commit, with something like OSSubprocess-MarianoMartinezPeck.7. However, when browse the repository later from MC, I get that such a commit is displayed as OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message maps correctly).
Could this offset be because of the first initial 3 commits? That is, initial git commit from github, and 2 commits of "gitfiletree repository properties".
Is there a workaround here so that both could map correctly?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Mariano http://marianopeck.wordpress.com
Le 03/01/2016 17:04, Mariano Martinez Peck a écrit :
Hi Thierry,
When I commit from MC, I see the generated commit, with something like OSSubprocess-MarianoMartinezPeck.7. However, when browse the repository later from MC, I get that such a commit is displayed as OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message maps correctly).
Could this offset be because of the first initial 3 commits? That is, initial git commit from github, and 2 commits of "gitfiletree repository properties".
This is because Monticello pre-computes a version number without asking the repository about it... And GitFileTree disregard that version number (the 'filetree' metadata) and recomputes a version number from the git log history.
Is there a workaround here so that both could map correctly?
Yes. The latest Pharo5.0 development version of GitFileTree does a become to force Monticello to refer to the git saved version afterwards. But... 1- The GUI still shows the MC-computed version not the git one :( 2- The package copy stored into package-cache is at the MC version and not the git one. Maybe there is something to consider there about the model behind Monticello when doing all those operations, especially 2-. At the moment, MC behaves like the package-cache has priority on the specifics of the real repository you are saving to :( (and maybe this is where the solution is: highjack save so that the package-cache copy is done later...). Thierry
On Sun, Jan 3, 2016 at 1:17 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 03/01/2016 17:04, Mariano Martinez Peck a écrit :
Hi Thierry,
When I commit from MC, I see the generated commit, with something like OSSubprocess-MarianoMartinezPeck.7. However, when browse the repository later from MC, I get that such a commit is displayed as OSSubprocess-MarianoMartinezPeck.4 (the rest of the commit message maps correctly).
Could this offset be because of the first initial 3 commits? That is, initial git commit from github, and 2 commits of "gitfiletree repository properties".
This is because Monticello pre-computes a version number without asking the repository about it... And GitFileTree disregard that version number (the 'filetree' metadata) and recomputes a version number from the git log history.
Is there a workaround here so that both could map correctly?
Yes. The latest Pharo5.0 development version of GitFileTree does a become to force Monticello to refer to the git saved version afterwards.
OK, something is something!!
But...
1- The GUI still shows the MC-computed version not the git one :(
2- The package copy stored into package-cache is at the MC version and not the git one.
Maybe there is something to consider there about the model behind Monticello when doing all those operations, especially 2-. At the moment, MC behaves like the package-cache has priority on the specifics of the real repository you are saving to :(
you need a brave soul for that task hahahaha! I guess I will give it a try to bleeding edge then. BTW...if you ever happen to fix any of those points please let me know! pd: damn, you #pwd: usage of OSProcess made me another complicated issue to solve via FFI hahahahah -- Mariano http://marianopeck.wordpress.com
participants (3)
-
Alexandre Bergel -
Mariano Martinez Peck -
Thierry Goubier