does adopt work for repairing ancestry?

[dalehenrich]

The expected life cycle for packages stored in disk-based repositories (like git and svn) is:

1. aaa-dkh.1.mcz created as mcz file
2. aaa-dkh.2.mcz created as mcz file (ancestor aaa-dkh.1.mcz)
3. aaa-dkh.3.mcz created as mcz file (ancestor aaa-dkh.2.mcz)
4. aaa-dkh.3 copied to filetree repository (empty ancestry)
5. aaa-dkh.4 created in filetree repository (empty ancestry)
6. aaa-dalehenrichs.4 .mcz created as mcz file (ancestor aaa-dkh.3.mcz)

Now the situation exists where one would like to merge aaa-dalehenrichs.4 .mcz into aaa-dkh.4 in the filetree repository ...

In order for this to work i postulate that the following steps would work:

1. load aaa-dkh.4 into image
2. ADOPT aaa-dkh.3.mcz as ancestor (I think thats the sematics of adopt)
3. now merge aaa-dalehenrichs.4 .mcz and aaa-dkh.3.mcz should be the common ancestor

If these steps don't work we'll have to come up with something that will work ... otherwise we'll have to keep up-to-date ancestry information in the filetree repository which is not desirable...

[dalehenrich]

Adopt does appear to work correctly ... at least it restores the history of the file to what I want ... we can afford to leave the handling of versions in filetree as is ...

[ottobehrens]

Wow, nice one. Must pick the correct one to adpot. Perhaps can get some info from the git commit / version file. Very interesting

[dalehenrich]

Ah yes, good point ... perhaps we should create an ancestor file in the repository that records the version information for the immediate ancestor of package when it is stuffed into the repository (that isn't changed over time) so that one can easily know the immediate ancestor ... I'll reopen this one and address it ...

[dalehenrich]

1. If we really want to be faithful to the ancestry, we need to rewrite the ancestry on every commit.

YUCK!

1. If we want to allow for simple merges of non-filetree packages, we can afford to write the original ancestry and preserve the ancestry over time as suggested above...
2. If we don' t care about ever doing a Monticello merge, we might be able to get away with no ancestry ..

HOLD THE HORSES, what if we have a dirty package in the image and do a pull from git and we want to then merge the changes into our existing work in the image ... we need a common ancestor for the two packages and that may mean that we have to use option #1 all of the time ...

More thought needed...

[ottobehrens]

1. If we really want to be faithful to the ancestry, we need to rewrite the ancestry on every commit.

YUCK!

Yes; we've got a package with > 1000 versions. When loading this
package, the bit that takes the longest is to parse the ancestry file.
Perhaps a "prune" will help.

1. If we want to allow for simple merges of non-filetree packages, we can afford to write the original ancestry and preserve the ancestry over time as suggested above...
2. If we don' t care about ever doing a Monticello merge, we might be able to get away with no ancestry ..

HOLD THE HORSES, what if we have a dirty package in the image and do a pull from git and we want to then merge the changes into our existing work in the image ... we need a common ancestor for the two packages and that may mean that we have to use option #1 all of the time ...

Currently, we don't pull the git repo with dirty packages in the
image. Our workflow is to commit local changes from the image first
(save it to the file tree) and commit it in the local git repo.
Pulling then merges and we reload into the image.

In principle, even with Monticello, we avoided merging when a local
package is dirty. It's "safer" to "snapshot" my local changes before I
merge, because I can always then compare the 2 versions. So that bit
does not bother. It is a bit painful to go from the file tree to the
image, back again, merge in git, load the merge. Takes some time.

I was thinking one could use the history available in git to determine
the ancestry. All the information is there. I'll have to explore a bit
to figure out how.

Git "3 way" merge is actually quite good.

Yes, more thinking needed

[dalehenrich]

Otto,

Right ... that's the model that I've adopted as well (commit dirty packages to git first)...So really the only times when we need to really worry about ancestry in a package is when someone who is not used to using git ends up with a dirty package in the image and wants to merge using Monticello instead of git ...

One idea would be to make the loading of ancestry an option (on by default) that git users would just turn off, because they know what they are doing.

Combine that with the ability to reconstruct the ancestry would be cool ...

Dale

----- Original Message -----
| From: "ottobehrens" reply@reply.github.com
| To: "Dale Henrichs" dhenrich@vmware.com
| Sent: Thursday, February 9, 2012 11:43:30 PM
| Subject: Re: [filetree] does adopt work for repairing ancestry? (#2)
|
| > 1. If we really want to be faithful to the ancestry, we need to
| > rewrite the ancestry on every commit.
| >
| > YUCK!
|
| Yes; we've got a package with > 1000 versions. When loading this
| package, the bit that takes the longest is to parse the ancestry
| file.
| Perhaps a "prune" will help.
|
| > 2. If we want to allow for simple merges of non-filetree packages,
| > we can afford to write the original ancestry and preserve the
| > ancestry over time as suggested above...
| >
| > 3. If we don' t care about ever doing a Monticello merge, we might
| > be able to get away with no ancestry ..
| >
| > HOLD THE HORSES, what if we have a dirty package in the image and
| > do a pull from git and we want to then merge the changes into our
| > existing work in the image ... we need a common ancestor for the
| > two packages and that may mean that we have to use option #1 all
| > of the time ...
|
| Currently, we don't pull the git repo with dirty packages in the
| image. Our workflow is to commit local changes from the image first
| (save it to the file tree) and commit it in the local git repo.
| Pulling then merges and we reload into the image.
|
| In principle, even with Monticello, we avoided merging when a local
| package is dirty. It's "safer" to "snapshot" my local changes before
| I
| merge, because I can always then compare the 2 versions. So that bit
| does not bother. It is a bit painful to go from the file tree to the
| image, back again, merge in git, load the merge. Takes some time.
|
| I was thinking one could use the history available in git to
| determine
| the ancestry. All the information is there. I'll have to explore a
| bit
| to figure out how.
|
| Git "3 way" merge is actually quite good.
|
| Yes, more thinking needed
|
| ---
| Reply to this email directly or view it on GitHub:
| #2 (comment)
|

[dalehenrich]

I'm going to restore the writing/reading of ancestry info for fileTree packages ... it's ugly right now, but I think it is the only way to make it easy for folks to migrate to using filtree/git/github. If the ancestry is preserved across package lifetimes within a filetree/git/guthub repository, the perceived cost of taking a run at using github is much much lower (no waving hands about setting flags or having to remember to adopt) ...

I agree 100% that the three way merge for git is superior ... it recognizes renames and method moves and preserves history across ...

I'm preserving ancestry so folks have fewer surprises whtn taking github for a spin ...

[dalehenrich]

Of course when you do use git merge, you have to pick the correct ancestry for the file and when doing a git merge, there might not be a correct answer ...

[dalehenrich]

fixed in SHA: 709545a

In the future we might make it optional to store ancestry (leverage pkg properties).