filetree
filetree copied to clipboard
dalehenrich
Update tests package versions to track git state
Would it be possible to push new versions of the test packages to make sure they are coherent with their version metadata ?
Test packages for issues 72 and 33 have changes after their last version committed, and this forces me, when porting those tests to gitfiletree://, to change the tests check to account for the differences in the package when reading the package as committed with their version metadata (instead of the filetree:// method of reading the HEAD state of the git repository).
I'm open to the suggestion that gitfiletree: should handle a special package version called HEAD :)
I'm not sure what you mean by this:
Test packages for issues 72 and 73 have changes after their last version committed
The test package for Issue #72 was created to include utf8 characters in the Monticello meta data ... if you are eliminating Monticello meta data with your recent work (I will learn more about what you have been doing when I review the pull request ... BTW I'm very busy for the next week or so and wil not have a lot of time to look at FileTree) then then test isn't necessary for what you are doing.
The test package for Issue #33 was created to include a sample fo Method Metadata for Monticello as well ...
Finally the test repositories need to remain constant as they serve as examples of old (supported) FileTree formats and the standard FileTree reader must be able to read the older formats ...
Your new variant of FileTree (with a different repository identifier) does not need to be backward compatible and probably doesn't even need to support the Monticello metadata ...
What I mean is that if I look at the timestamps in the metadata for issue 33, I see that the latest change is the commit 'tweak the timestamps' : f8daa1be31418b4432cb52413261d2bdeb4bd8f2. However, as in gitfiletree:// I will read the package based on the timestamp of the monticello.meta/version file, which is the commit b36f0a2532aaa4c995108ff6cb1363a4297bbf59, then I have not the right timestamps when comparing to the expected values (MCTestIssue33). It's the same issue in Test72: the HEAD of the test package is one commit ahead of the version, and, as a consequence, the package metadata to check against is out of date in my case.
It's not very important in itself, but it would have made testing for me a bit easier.
As for now, I have kept the test repositories constant and changed the expected values. Having this issue will also document the reason for using a slightly different reference data for validating the tests with gitfiletree on the very same test repository and test cases than the filetree ones.
In my opinion, I prefer to stay compatible with the existing filetree format, even if I may have some issues with it (or more honestly, git may not like it so much, creating conflicts when merging). It allows you to cleanly open and search and compare an existing filetree under git repo with hundreds of versions of a large MC package, which I found very convenient. It also makes working on the filetree repository itself a breeze. And there is a reuse of a fairly well thought out format.
Now, if you ask me to design a git-oriented format, I have a better idea about what would be needed to make the implementation a bit simpler, easier to make it fast, and how to design it to allow git to merge it cleanly. But let's say it's not that essential for now; there is a lot of interesting stuff to be done with the current format and the power of git.
@ThierryGoubier, just out of curiousity, have you addressed this issue in your recent changes or do we still need to do something?
I haven't done anything about this issue, and my tests are adjusted to use the current state of FileTree-Tests (I think the version is -dkh.34).
Okay, if I understand things correctly you are using the timestamp of the monticello.meta/version file as the official timestamp for the package?
I guess I would hope that we would be able to eventually eliminate the need to keep the monticello meta data and the method timestamp files are there because we don't have access to the git data...
If by timestamp you mean the commitID given by git, yes. I use the commitID (as per git) of the monticello.meta/version file as the official commitID for the package overall. I had to decide that the package definition is the one to use when you "save" it via monticello, and all subsequent commits belong to the next package version...
If a package version is committed multiple times, I see multiple times the same version in git, and its a bit unusual in the GUI: you can only select the first one.
Okay ... that explains things a bit ... because of the nature of the multiple platform work I don't always use monticello to update information in the repository, the monticello version meta data is not always updated ... in the case of the tests, I assume that I was concerned that the meta data (used by tests) was propogated out to multiple branches and I needed to make a change to the test data that I could propagate without also having to propagate tests everywhere (which would involve merging) ... so that problem still exists ...
I want the test repositories to be identical across all branches ... so if we do changed the test repository we need to propagate that change to all branches (by a cherry-pick of ideally one commit to the master and then merging master into all branches) and fix up tests along the way ...
Dale
----- Original Message -----
| From: "Thierry Goubier" [email protected] | To: "dalehenrich/filetree" [email protected] | Cc: "Dale Henrichs" [email protected] | Sent: Sunday, July 7, 2013 9:11:05 AM | Subject: Re: [filetree] Update tests package versions to track git | state (#84)
| If by timestamp you mean the commitID given by git, yes. I use the | commitID (as per git) of the monticello.meta/version file as the | official commitID for the package overall. I had to decide that the | package definition is the one to use when you "save" it via | monticello, and all subsequent commits belong to the next package | version... | If a package version is committed multiple times, I see multiple | times the same version in git, and its a bit unusual in the GUI: you | can only select the first one. | — | Reply to this email directly or view it on GitHub .