taskManeage - Tasks: task #15942, Removing Metastore from Maneage

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #15942: Removing Metastore from Maneage

Submitter:  Mohammad Akhlaghi <makhlaghi>
Submitted:  Sun 11 Apr 2021 01:50:14 PM UTC
   
 
Should Start On:  Sat 10 Apr 2021 11:00:00 PM UTC Should be Finished on:  Sat 10 Apr 2021 11:00:00 PM UTC
Category:  Software Priority:  5 - Normal
Status:  Postponed Privacy:  Public
Assigned to:  None Percent Complete:  0%
Open/Closed:  Open Effort:  0.00

Sun 11 Apr 2021 09:36:41 PM UTC, comment #5: 

See bug https://savannah.nongnu.org/bugs/index.php?60376

So I have to expand on my previous comment:

> I've never looked at how metastore works,


That remains correct, but it also seems that metastore has not been installed for me, and I have not benefited (or suffered) from metastore so far, and have survived without it. So I can only claim that it seems that metastore would be useful.

It's difficult to object to its removal based purely on an expectation that it would be useful, especially given the original description of metastore having some problems.





Boud Roukema <boud>
Group Member
Sun 11 Apr 2021 07:28:37 PM UTC, comment #4: 

Hi Boud, the two raw hooks are in the reproduce/software/shell directory: git-post-checkout and git-pre-commit.

After Metastore is build in basic.mk, we edit those raw files and put them in the '.git' directory.

 Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 11 Apr 2021 07:04:31 PM UTC, comment #3: 

I agree that having our own plain-text only alternative to metastore, as explained in https://savannah.nongnu.org/task/?15363 , would be a sufficient alternative to metastore. :)

I'm wondering where the metastore git hooks are currently stored. I don't see any non-sample files in .git/hooks/ ; I only see  .git/hooks/*.sample . I'm not volunteering to write this, but without knowing how the hooks work currently, someone looking here won't know how to get started...

Boud Roukema <boud>
Group Member
Sun 11 Apr 2021 03:49:16 PM UTC, comment #2: 

Thanks Boud, if you feel it can still be useful we can keep it. Just as a small note, based on my experience so far, its not necessary to keep two builds to checkout between branches ;-).

In the main task definition, I forgot to mention task #15363 (titled "Better solution to restoring file dates after Git checkout"). That task was defined for two reasons:

  • What meta-store does can easily be done in a simple shell script that stores the database in plain-text (and thus better visible in Git).
  • In Maneage, we are actually using my fork of Metastore, not the main work.


So hopefully once we implement task #15363, we can also remove the need for meta-store.

One of the reasons for this task is that after more than 2 years of my fork, and the Github pull-request, the Metastore maintainer finally replied and thinks that the added features aren't useful for it. So we need to maintain our own separate fork if we want to continue using it (which can be annoying).

 Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 11 Apr 2021 03:23:14 PM UTC, comment #1: 

I think that removing the metastore file timestamping would completely defeat the power of using make and makefiles.

There are many good reasons for switching between branches other than updating to a new Maneage version. The power of git is that it is very convenient and easy to switch back and forth between commits and branches. However, I'm not aware of any git options that are able to backdate the timestamps to those of the commit when the file was most recently updated. If there does exist such an option in git, then that would provide an alternative to metastore.

However, it doesn't look like git developers agree with the problem:
https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F

I think the issue of interest is effectively a question of the version history of git navigation . If I do a few git checkouts and then do what I think of as reverting that sequence of git checkouts, then it should be possible to return to the original timestamps, provided that I didn't do any build steps (such as ./project make ) during these steps.

However, this would require tracking the sequence of git checkouts, and it would be tracking that normally would not be worth storing (except for studying how someone was trying to debug and analyse something), but would be useful in practical terms for deciding when the restoral of old timestamps is justified. This would require an extra layer of overhead, and possibly a lot of extra complications, unless, for example, only the last N (e.g. 5 or 10) checkouts were stored as "undoable".

I do not expect that this sort of "git undo" capability is something that any of us would want to try implementing.

If metastore were removed, then users would effectively be forced to have at least two installs: one for "production", and one for development. This immediately doubles the disk space requirements, and the time requirements for the initial configure cycle.

I've never looked at how metastore works, but to me it seems like a key attraction of maneage and it would be a pity to remove it.


Boud Roukema <boud>
Group Member
Sun 11 Apr 2021 01:50:14 PM UTC, original submission:  

Currently we are using metastore in Maneage to keep the date of files between checkouts.

The main reason was this: suppose you are running a project that takes 5 days to build (and of course the analysis depends on some of our project's configuration files, and thus the dates of those files). But when you checkout to the 'maneage' branch, pull the most recent changes and then checkout back to your project branch, the dates of all your project-specific files will be reset to the current date! As a result, next time you run './project make' it will re-do everything (which is terribly annoying!).

With meta-store, the dates of files (generally the file metadata) is stored in a binary file and a hook is added before a commit and after a checkout to call Metastore and reset the dates.

However, in the last few years since adding it it has caused more problems than benefits and having to carry around the binary file is very annoying. There are two simple solutions to avoid the need:

  • Do the merge with Maneage when you want to do a clean re-build (which is of course the best and most recommended way to catch possible changes in infrastructre!).
  • Do the merge on a different directory, push the merge to your repository and pull from your project branch in your main project.


With this task, I am suggesting to remove metastore from Maneage and add notices on these alternative solutions.

Mohammad Akhlaghi <makhlaghi>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items
taskBetter solution to restoring file dates after Git checkout (task #15363, Postponed)

Digest:
   task dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by boud (Posted a comment)
  • -email is unavailable- added by makhlaghi (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-13 boud Dependencies- Depends on task #15363

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-54b4.
    Corresponding source code