I can, and do, but there are a couple of added wrinkles:
- I want to have multiple concurrent slices through the same checked out codebase
If I'm working on multiple bugs at the same time, each one may involve up to a dozen files, easily (sometimes double that... I never claimed the code was sane, I came onto the project late). A single .tm_properties at the root to provide a subset would need to be tweaked constantly for the task at hand, quickly eliminating any productivity gains from the effort. There are, at last check just now, 17810 files in the default check out of the main codebase, with 169 folders at the top level alone. That's a lot to work with to separate the interesting bits from the chaff.
- I want to have a list of files associated with a task that I can retarget at different checked out versions
Useful for regression testing, I want to be able to quickly ascertain the state of a task across different client projects, each of which has a working copy of the main code base. (Look, I *said* it isn't well organized... unfortunately, I can't change that without a complete overhaul of our build environment, which I'm working on gaining support for.) I may be able to replicate this with Allan's hint above, but it requires me to set things up each time.
.tmproj files solved both of these at one shot, rather effortlessly.
I might be able to fake some of the above with a symlink to a suite of .tm_properties files, one for each slice, and then use Allan's hint for the retargeting. It just won't be as slick and quick, nor will it provide the ease of setup that I had before. It may be better to set up a series of directories of symlinks into the code bases, and Allan's retargeting hint, but I'm unclear on how that will interact with the version control bundles.
On Thu, Sep 20, 2012 at 3:27 PM, Phil Schumm pschumm@uchicago.edu wrote:
On Sep 20, 2012, at 4:21 PM, Jason McC. Smith wrote:
The .tm_properties files are insanely powerful, and are an improvement in general, from a basic infrastructure point of view. They just don't work for what is, really, a rather common work environment constraint: no local config files for a specific developer may pollute the central code repositories.
I may be missing something here, but can't you simply add .tm_properties to the appropriate .gitignore/.hgignore/etc. file(s)? I do this rather frequently in cases where I am working with a group in which I'm the only TextMate user.
-- Phil
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate