|
|
Login/Become a Member! | 28 Comments
|
| | Comments are owned by the poster. We aren't responsible for their content. |
Re: An Interview with Tom Lord of Arch on Versioning Systems
(Score: 0)
by Anonymous on Sep 24, 2004 - 02:54 PM
|
The main rationale (from what I know) is that arch does not want to answer a question for you. That question is: What determines whether you want to add those files or not?
One common fix -- which makes a lot of sense for non-version-control reasons as well -- is using out-of-tree builds. In one project of mine that uses arch, I have two build subdirectories. Call them +a and +b; each one corresponds to a major configure-time feature set. In other projects, I just have one build subdirectory, +build. The default inventory regexps for tla recognize files and directories that start with + as "precious": A file it should keep but not put in version control.
You could, of course, add inventory rules (in {arch}/=tagging-method or .arch-inventory) to regard your other generated files as junk, backup or precious. In the long run, that is a lot higher maintenance than using out-of-tree builds.
|
Re: An Interview with Tom Lord of Arch on Versioning Systems
(Score: 0)
by Anonymous on Sep 24, 2004 - 03:04 PM
|
I completely agree.
Although it is painful when you do an update, forget to add a file, and then it breaks for everyone else because they don't get the needed file when they update - if we instead forced a clean compile after every checkin (due to requiring a 'clean' before checkin) would be considered so costly for many developers that they would start making fewer, monolithic checkins instead of many, minor, incremental checkins.
I'd love to see an answer to this posted...
|
Re: An Interview with Tom Lord of Arch on Versioning Systems
(Score: 2, Informative)
by Anonymous on Sep 24, 2004 - 03:28 PM
|
The problem is that you are building
things in the same directory as your
source code. This really only serves
to mess up an otherwise neat file structure.
Instead, build your code in an alternative
directory (one say beginning with an
equals sign (that arch will ignore)
say './=build/'), and make use of
the VPATH functionality of gnu Make.
The result will be a clean separation of
source from builds, and will allow
arch to function as it was intended.
(The problem you highlighted is actually
a FEATURE of arch to encourage such separation
of source from builds.)
|
Re: An Interview with Tom Lord of Arch on Versioning Systems
(Score: 1, Informative)
by Anonymous on Sep 25, 2004 - 02:45 AM
|
It is possible to change arch default behaviour to accept unclean tree, by tuning the {arch}/=tagging-method file, with:
untagged-source precious
junk ^$
precious ^$
backup ^$
unrecognized ^$
source ^[_=a-zA-Z0-9].*$
Then, it will just warn about untagged file present in your tree (as does CVS), but happily let you perform commit and all other operation. You can then tweak those regexp globally to exclude some file (similar to the CVS .cvsignore file), or locally for a directory in the .arch-inventory file.
(Well in fact, it is only needed to set the unrecognized regexp to ^$ since arch will only stop if a file is classified as unrecognized.)
|
Re: An Interview with Tom Lord of Arch on Versioning Systems
(Score: 0)
by Anonymous on Sep 27, 2004 - 10:28 AM
|
It sounds like you may have missed something, not surprising, given the state of the arch/arx/larch/tla documentation. Arch can operate in two modes: classify by file-pattern, or by explicit commands (e.g. "add") like CVS/subversion.
Now, you wouldn't be saying that you are using explicit style, but you still have problems? I don't run into that. TLA (Tom Lord's Arch) is the release I use, and it may note that some files look like "source", but still allows any/all operations. I'd recommend explicity-style for most people, especially if you are coming from other source-code-control systems.
|
|
|