Opened 7 years ago
Closed 7 years ago
#1939 closed Enhancement (fixed)
Add sorting of cfg.txt to makenemo
Reported by: | mdunphy | Owned by: | nicolasmartin |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | env | Version: | trunk |
Severity: | minor | Keywords: | makenemo, |
Cc: |
Description
Context
makenemo rewrites cfg.txt at build time, putting the most recently built config at the bottom of cfg.txt. This changes the file in the eyes of version control, but the changes are not real (it's just a reordering of the lines). If we always sort the cfg.txt file, then version control only sees changes when a config is added/removed/modified, and this reduces version control churn
Changes
One line added in makenemo to sort cfg.txt, patch included. This has been tested under linux and is working without issue
Commit History (1)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
8647 | nicolasmartin | 2017-10-20T14:01:16+02:00 | Revert the import of local configs into cfg.txt, really should work on it [refs #1939] |
Attachments (1)
Change History (11)
Changed 7 years ago by mdunphy
comment:1 Changed 7 years ago by acc
Does this change alter the behaviour of makenemo when run without arguments? It is a nice feature that, after the initial, verbose invocation of makenemo to build a configuration, the user does not need to specify the configuration again on subsequent makes unless switching configurations. If the position of the configuration in cfg.txt is determining which configuration is built then sorting after every use will destroy this feature. If so then I'd rather folks were just more careful about only submitting intended changes but into the repository.
comment:2 Changed 7 years ago by mdunphy
Ah yes, it does break that behaviour. Did not notice as I always specify the config to makenemo. Fair enough -- maybe this change isn't right for upstream.
comment:3 Changed 7 years ago by nicolasmartin
I understand your points.
I always been quite uncomfortable about the way we handle this, we shouldn't modify any versioned files as long as we launch a reference configuration without change or create a new one.
A few times, I was stuck for a while because I had discarded from the outset the check of cfg.txt which is always 'M' flagged in svn diff outcome. But I certainly lack a little practice.
We surely can improve the overall procedure of makenemo but we have to be careful not to loss its existing functionalities.
comment:4 Changed 7 years ago by acc
Nicolas, Could we do something with a hook script in the repository? Perhaps sort the incoming cfg.txt and only commit if it has changed? Or perhaps just abort the commit if the cfg.txt file hasn't been sorted? This would force folks to manually sort cfg.txt before committing but not impose a reordering whilst developing between commits.
comment:5 Changed 7 years ago by mdunphy
Since we are caching some elements of the most recent build under NEMOGCM/TOOLS/COMPILE (arch.history, arch_nemo.fcm, cpp.history), we could add a new file there (config.history) containing the most recently built config name. That would be more consistent and impose no sorting requirement on cfg.txt (vcs hooked or otherwise)
comment:6 Changed 7 years ago by nicolasmartin
- Owner changed from nemo to nicolasmartin
- Status changed from new to assigned
comment:7 Changed 7 years ago by nicolasmartin
- Milestone set to 2017 WP
comment:8 Changed 7 years ago by nicolasmartin
In 8647:
comment:9 Changed 7 years ago by nicolasmartin
- Milestone 2017 WP deleted
comment:10 Changed 7 years ago by nicolasmartin
- Keywords makenemo added
- Resolution set to fixed
- Severity set to minor
- Status changed from assigned to closed
- Version changed from v3.6 to trunk
A new procedure has been implemented into makenemo in the trunk to better handle the build of configurations [9651]:
- Ref. cfgs are stored on a versioned file ref_cfgs.txt which will no longer be modified by makenemo, the end user can add its own configurations if he wants to.
- Working cfgs will be created by makenemo and listed in an unversioned file work_cfgs.txt, everything that is done with it will have no consequences.
From that, we should no longer see any inconsistency in the ref. cfgs between the list in the txt file and the folders included.
The same process will be at work for ./cfgs and ./tests root directories.
One line patch to add cfg.txt sorting