#139 vupdate -exclude switch
jim.huggins@intel.com
Recently we thought of a need for a new switch to the vupdate tool. Currently we use a set of arguments to have vupdate automatically advance/update checkouts owned by the user. While this is typically desirable, we happen to have a build where there are references to two versions for each of the project sources. One reference is used as a "base" version while a second reference is the latest version. This has been done in order to support the notion of incremental compiles (for compile tools which explicitly have such notions and require "base" results as inputs).
The problem we ran into is wanting to update the "base" versions to whatever is the "latest" versions happen to be pointing at. The idea here is the user wants to mark their current build versions as the new incremental base point. This operation is easy to do as it only means to copy the versions from the "latest" .ves's to the "base" .ves's. However, after doing this copy, the "base" versions will get continually updated by vupdate since the copy operation copied a reference to a local checkout.
The solution being suggested here is a new switch to vupdate which can inform it of sub-directories and/or .ves files which should not be touched. In the case of a sub-dir name any .ves in that sub-dir and any sub-dir below it should be excluded from any updates. It might be handy to take this exclude argument more than once to exclude multiple dirs and/or files.
Logged In: YES
user_id=304837
Originator: NO
First of all, before we decide to implement this, I have to
ask whether there's a reason why the existing /**noupdate**/
capability isn't sufficient. (See the vupdate man page for
a description.)
I believe the intention is for the proposed -exclude switch
to affect which SDL model files the -r (aka -update-local),
-c (aka -update-checkout), and -u (aka -update-all) options
will cause vupdate to recurse into. I assume that "-exclude
foo" would prevent recursion into any model files whose name
or path contains the string "foo". This doesn't seem
unreasonable to me, but I'd like to clarify a few things:
1. When matching a model file path for exclusion, should
its entire path be used, or just its partial path within a
working directory or an immutable version? The latter
would be more work, so I'd prefer to match against the
entire path.
2. If we do allow matching against the full path, when
recursing through a reference to an active checkout (the
feature that -c and -u turn on), should we match against
the immutable path that's imported, the mutable path of
the file being modified, or both? I think we should
probably match against both.
I'm also concerned about confusion that -exclude may create,
as there is already the -limit option. They sound related,
but they really wouldn't be. (-limit limits which model
imports get updated, but the proposed -exclude would exclude
files from being recursed into.) That could be confusing
for users. I'd like to hear some ideas on how to resolve
this.
Logged In: YES
user_id=304837
Originator: NO
After talking with Jim about his feature request, we came to the
conclusion that /**noupdate**/ would be sufficient if it suppressed
recursion by the -r/-c/-u flags. Currently it seems that it prevents
recursion into non-local imports, but doesn't prevent recursion into
local imports. That would be a much simpler change to make than
adding an entirely new flag to vupdate.
For his use case, currently he would have to write a script that would
modify multiple SDL model files to add /**noupdate**/ at all the
non-local imports. This script would then be run whenever his
automation copied in new files specifying his "base" version. If
/**noupdate**/ prevented recursion into local imports, he could add a
single /**noupdate**/ once.