reproduce-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[task #15942] Removing Metastore from Maneage


From: Boud Roukema
Subject: [task #15942] Removing Metastore from Maneage
Date: Sun, 11 Apr 2021 11:23:15 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #1, task #15942 (project reproduce):

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.



    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?15942>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]