Problem with gitfiletree numeration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with gitfiletree numeration

Mariano Martinez Peck
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ??

How do you normally solve this?

Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Thierry Goubier


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.

(I'm still considering numbering gitfiletree versions with their SHA commit, but... MC expects numbers, and ordering matters in non-git repositories)

Thierry
 

Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Mariano Martinez Peck


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Thanks!

--
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Thierry Goubier


2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Yes!

It used to work out of the box in the right order, but I now make sure to push the versions in the right order when I do that (push starting with the smallest version number).

Thierry
 

Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Mariano Martinez Peck

On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Yes!
\

OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1  is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc...
Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1  from shub and override the OSSubprocess-MarianoMartinezPeck.1  from gitfiletree?

Or...at least a way to remove everything and start fresh with the fecth/push???

mmm

 
It used to work out of the box in the right order, but I now make sure to push the versions in the right order when I do that (push starting with the smallest version number).

Thierry
 




--
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Thierry Goubier


2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <[hidden email]>:

On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Yes!
\

OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1  is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc...
 
Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1  from shub and override the OSSubprocess-MarianoMartinezPeck.1  from gitfiletree?

Yes. You can reset in git to a previous commit, I think it is with git --reset .

But this is problematic if it was pushed on github.
 

Or...at least a way to remove everything and start fresh with the fecth/push???

Yes, but, again, problematic if it was pushed to github.

Thierry
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Mariano Martinez Peck


On Wed, Jan 13, 2016 at 11:33 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <[hidden email]>:

On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Yes!
\

OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1  is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc...
 
Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1  from shub and override the OSSubprocess-MarianoMartinezPeck.1  from gitfiletree?

Yes. You can reset in git to a previous commit, I think it is with git --reset .

But this is problematic if it was pushed on github.
 

Or...at least a way to remove everything and start fresh with the fecth/push???

Yes, but, again, problematic if it was pushed to github.

Thierry

It was pushed to github :(


Let me ask... do you think my assumption is correct that it could bother me when watching the history via MC browser, or a merge or .. any kind of MC operation that would be screw up because of this?   
If this is not the case, then...ok, I can live with that mistake.

 
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

David Allouche
In reply to this post by Thierry Goubier

On 13 Jan 2016, at 15:33, Thierry Goubier <[hidden email]> wrote:



2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <[hidden email]>:

On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Yes!
\

OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1  is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc...
 
Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1  from shub and override the OSSubprocess-MarianoMartinezPeck.1  from gitfiletree?

Yes. You can reset in git to a previous commit, I think it is with git --reset .

But this is problematic if it was pushed on github.
 

Or...at least a way to remove everything and start fresh with the fecth/push???

Yes, but, again, problematic if it was pushed to github.

Thierry


Removing commits from a git branch is only really problematic if there are outstanding, unmerged branches out there, since it tends to cause false merge conflicts.

Locals clones of the public repository WILL complain about a divergence, but they can be fixed by "git pull --force". That is probably acceptable in your context, since you appear to be in a "botched history" situation.

Taking a step back, any distributed version control that uses explicit revision numbers for ordering is broken by design. Yes, Monticello, I am looking at you.

That was one of the design mistakes of GNU Arch, and the reason why all the DVCS that followed it (bzr, hg, git) identify revisions by UUIDs and define ordering exclusively by the ancestry graph. Experience has also shown that using content-based UUIDs like hg and git is preferable, for performance and integrity, to using arbitrary UUIDs like bzr did.

Disclaimer: I am (not yet) familiar with the Monticello model, so I might be all wrong. But I am quite knowledgeable about DVCS design in general.



Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Thierry Goubier
In reply to this post by Mariano Martinez Peck


2016-01-13 15:44 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 11:33 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <[hidden email]>:

On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Yes!
\

OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1  is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc...
 
Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1  from shub and override the OSSubprocess-MarianoMartinezPeck.1  from gitfiletree?

Yes. You can reset in git to a previous commit, I think it is with git --reset .

But this is problematic if it was pushed on github.
 

Or...at least a way to remove everything and start fresh with the fecth/push???

Yes, but, again, problematic if it was pushed to github.

Thierry

It was pushed to github :(


:( But deleting on github, resetting on your own repo, recreating on github and pushing shouldn't take you very long.
 

Let me ask... do you think my assumption is correct that it could bother me when watching the history via MC browser, or a merge or .. any kind of MC operation that would be screw up because of this?   
If this is not the case, then...ok, I can live with that mistake.

No, it shouldn't bother you neither make any operation problematic.

Thierry
 

Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Thierry Goubier
In reply to this post by David Allouche


2016-01-13 15:46 GMT+01:00 David Allouche <[hidden email]>:

On 13 Jan 2016, at 15:33, Thierry Goubier <[hidden email]> wrote:



2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <[hidden email]>:

On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Yes!
\

OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1  is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc...
 
Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1  from shub and override the OSSubprocess-MarianoMartinezPeck.1  from gitfiletree?

Yes. You can reset in git to a previous commit, I think it is with git --reset .

But this is problematic if it was pushed on github.
 

Or...at least a way to remove everything and start fresh with the fecth/push???

Yes, but, again, problematic if it was pushed to github.

Thierry


Removing commits from a git branch is only really problematic if there are outstanding, unmerged branches out there, since it tends to cause false merge conflicts.

Locals clones of the public repository WILL complain about a divergence, but they can be fixed by "git pull --force". That is probably acceptable in your context, since you appear to be in a "botched history" situation.

Taking a step back, any distributed version control that uses explicit revision numbers for ordering is broken by design. Yes, Monticello, I am looking at you.

That was one of the design mistakes of GNU Arch, and the reason why all the DVCS that followed it (bzr, hg, git) identify revisions by UUIDs and define ordering exclusively by the ancestry graph. Experience has also shown that using content-based UUIDs like hg and git is preferable, for performance and integrity, to using arbitrary UUIDs like bzr did.

Good to know. I note the ordering by ancestry graph point; I think this could be significant.
 

Disclaimer: I am (not yet) familiar with the Monticello model, so I might be all wrong. But I am quite knowledgeable about DVCS design in general.

Monticello uses explicit revision numbers for ordering and version identification, has access to the full ancestry (in theory; in practice not[*]), and, rarely, uses arbitrary UUIDs to identify versions.

Thierry

[*] For the Pharo3 release, the ancestry of all core packages was erased from those packages because it was too large.


Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Mariano Martinez Peck
In reply to this post by Thierry Goubier


On Wed, Jan 13, 2016 at 11:48 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 15:44 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 11:33 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <[hidden email]>:

On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[hidden email]>:


On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <[hidden email]> wrote:


2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <[hidden email]>:
Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
 
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? 

How do you normally solve this?

The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work.


OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right?

Yes!
\

OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1  is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc...
 
Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1  from shub and override the OSSubprocess-MarianoMartinezPeck.1  from gitfiletree?

Yes. You can reset in git to a previous commit, I think it is with git --reset .

But this is problematic if it was pushed on github.
 

Or...at least a way to remove everything and start fresh with the fecth/push???

Yes, but, again, problematic if it was pushed to github.

Thierry

It was pushed to github :(


:( But deleting on github, resetting on your own repo, recreating on github and pushing shouldn't take you very long.
 

Thanks! That was easy indeed :)
 

Let me ask... do you think my assumption is correct that it could bother me when watching the history via MC browser, or a merge or .. any kind of MC operation that would be screw up because of this?   
If this is not the case, then...ok, I can live with that mistake.

No, it shouldn't bother you neither make any operation problematic.

Thierry
 




--
Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Ben Coman
In reply to this post by David Allouche
>>>>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck
>>>>> <[hidden email]>:
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I wanted to know how you manage this situation.
>>>>>> I had my already existing project in shub repo. Last version was
>>>>>> OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned
>>>>>> it, and then with gitfiletree I commit for the first time.
>>>>>>
>>>>>> The problem is that the commit I did with GitFileTree received this MC
>>>>>> version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But
>>>>>> in this case I do care because every in a while I would like to move/publish
>>>>>> some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1
>>>>>> has 2 problems:
>>>>>>
>>>>>> 1) It has an older version number but newer contents
>>>>>>
>>>>>> 2) It's number is not unique. So if I copy versions created from
>>>>>> github to shub, they would override those versiones created in shub (like
>>>>>> the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ??
>>>>>>
>>>>>>
>>>>>> How do you normally solve this?
>>>>>

On Wed, Jan 13, 2016 at 10:46 PM, David Allouche <[hidden email]> wrote:

>
> Removing commits from a git branch is only really problematic if there are
> outstanding, unmerged branches out there, since it tends to cause false
> merge conflicts.
>
> Locals clones of the public repository WILL complain about a divergence, but
> they can be fixed by "git pull --force". That is probably acceptable in your
> context, since you appear to be in a "botched history" situation.
>
> Taking a step back, any distributed version control that uses explicit
> revision numbers for ordering is broken by design. Yes, Monticello, I am
> looking at you.
>
> That was one of the design mistakes of GNU Arch, and the reason why all the
> DVCS that followed it (bzr, hg, git) identify revisions by UUIDs and define
> ordering exclusively by the ancestry graph. Experience has also shown that
> using content-based UUIDs like hg and git is preferable, for performance and
> integrity, to using arbitrary UUIDs like bzr did.
>
> Disclaimer: I am (not yet) familiar with the Monticello model, so I might be
> all wrong. But I am quite knowledgeable about DVCS design in general.

From the little I know about Monticello I believe you are correct.
Its a known problem - just no-one has got to tackle it yet.  I'm not
familiar with this space, but you may be interested in Ring [1] ,
Epicea [2], libgit[3], in-image github[4].

cheers -ben

[1] http://rmod.lille.inria.fr/archives/talks/2010-Smalltalks-Uquillas-Ring.pdf
[2] http://arxiv.org/pdf/1309.4334.pdf
[3] https://github.com/theseion/LibGit
[4] http://forum.world.st/Basic-versioning-of-GitHub-repositories-from-within-Pharo-td4862708.html#a4862785

Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

abergel
In reply to this post by Mariano Martinez Peck
Hi Mariano

Just wondering, are you using Spur? If yes, how come that you can use git? Osprocess does not work with Spur

Alexandre 

Le 13 janv. 2016 à 09:12, Mariano Martinez Peck <[hidden email]> a écrit :

Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ??

How do you normally solve this?

Reply | Threaded
Open this post in threaded view
|

Re: Problem with gitfiletree numeration

Mariano Martinez Peck


On Wed, Jan 13, 2016 at 9:33 PM, Alexandre Bergel <[hidden email]> wrote:
Hi Mariano

Just wondering, are you using Spur? If yes, how come that you can use git? Osprocess does not work with Spur


First, I am changing GitFileTree to use my soon-to-be-released OSSubprocess :)
Second, OSProcess SHOULD be fixed with the very last VM from CI:

wget -O- get.pharo.org/vmLatest50 | bash

Let me know if it worked.

Cheers,
 
Alexandre 

Le 13 janv. 2016 à 09:12, Mariano Martinez Peck <[hidden email]> a écrit :

Hi guys,

I wanted to know how you manage this situation. 
I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. 

The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems:

1) It has an older version number but newer contents
2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ??

How do you normally solve this?




--