2016-01-13 15:46 GMT+01:00 David Allouche <[email protected]>: > > On 13 Jan 2016, at 15:33, Thierry Goubier <[email protected]> > wrote: > > > > 2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <[email protected]>: > >> >> On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier < >> [email protected]> wrote: >> >>> >>> >>> 2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <[email protected]> >>> : >>> >>>> >>>> >>>> On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck < >>>>> [email protected]>: >>>>> >>>>>> 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.
