I am using a TM Project because I need to set a few project-local variables. Projects files, “.tmproj”s, are serialized to a single xml file, and included is information about window settings (position, size, drawer open?). For example, when you move the project window, your VCS will mark it as changed. This is very annoying.
Xcode solves this problems my separating the “project” and the project window settings, all contained inside a directory/
XcodeProject.xcodeproj/ project.pbxproj <----- The _real_ project file. myusername.mode1 <---- other stuff. myusername.pbxuser <---- more stuff.
-- Daniel
According to Daniel Harple:
file, and included is information about window settings (position, size, drawer open?). For example, when you move the project window, your VCS will mark it as changed. This is very annoying.
echo "*.tmproj" >>.hgignore hg commit -m "Don't handle TM project files."
(or use your local vcs instead of course)
Most people just don't keep the project file in version control, that way you can still have the advantage of if saving different window positions if you had multiple computers. Plus other people that don't use Textmate wouldn't be flustered by an unknown file. Other option that might work is to simply set it as you want it, then lock it. Havn't tested that though, Textmate might complain too much.
On May 31, 2006, at 8:59 PM, Ollivier Robert wrote:
echo "*.tmproj" >>.hgignore hg commit -m "Don't handle TM project files."
(or use your local vcs instead of course)
I tried this before —- in subversion (and darcs) you can not ignore version controlled files.
On May 31, 2006, at 9:04 PM, Michael Sheets wrote:
Most people just don't keep the project file in version control, that way you can still have the advantage of if saving different window positions if you had multiple computers.
Taking the file out of version control is not an option —- I need to have a few project-local variables set. Separating project settings and window settings does not take away the advantage you are describing -— it augments it. You can keep the project, “.tmsettings”, in version control and just ignore the user specific settings -— “.tmuser”.
project.tmproj/ project.tmsettings someuser.tmuser
Plus other people that don't use Textmate wouldn't be flustered by an unknown file. [...]
This is other person's problem if their world comes crashing down at sight of an unknown file. ;)
-- Daniel
On May 31, 2006, at 1:52 PM, Daniel Harple wrote:
XcodeProject.xcodeproj/ project.pbxproj <----- The _real_ project file. myusername.mode1 <---- other stuff. myusername.pbxuser <---- more stuff.
I'd have to say +1 for something like this. I have the same issues as well with SVN and the project file...
Regards, Eric
On 3/6/2006, at 9:43, Eric Coleman wrote:
XcodeProject.xcodeproj/ project.pbxproj <----- The _real_ project file. myusername.mode1 <---- other stuff. myusername.pbxuser <---- more stuff.
Allan,
Any chance of you implementing something like this :)
I have just committed an update to lib/bash_init.sh:
• add semi-experimental sourcing of all .textmate_init files found by going up the directory hierarchy, starting with the current directory and ending with either the users home directory or the root of the file system (whichever comes first)
The intent is that project specific variables should instead be stored in this file — in the current 1.5 branch this does degrade usability slightly, because there is no GUI support, but I believe that long-term this is a much better system, and 2.0 is likely to come with GUI support for this initialization procedure.
In other words, create a .textmate_init file in the project directory and let it contain e.g.:
export TM_LATEX_MASTER=master.tex
And then just forget about the project variables settable via the project drawer -- this of course starting with next build, unless you have a checkout of the Support directory.
Comments on this new system are of course welcome, as I am not fully decided on it yet, but I think it is the way to go, especially seeing how I do not want to rely on tmproj files for 2.0.
I like the project files, and that it keeps references & variables, HOWEVER, the issue is that it keeps track of window position and open files, so every time I do a commit the file is always modified.
If those were stored somewhere else it would be much easier to maintain..
Eric Coleman
On Jun 5, 2006, at 6:56 AM, Allan Odgaard wrote:
On 3/6/2006, at 9:43, Eric Coleman wrote:
XcodeProject.xcodeproj/ project.pbxproj <----- The _real_ project file. myusername.mode1 <---- other stuff. myusername.pbxuser <---- more stuff.
Allan,
Any chance of you implementing something like this :)
I have just committed an update to lib/bash_init.sh:
• add semi-experimental sourcing of all .textmate_init files found by going up the directory hierarchy, starting with the current directory and ending with either the users home directory or the root of the file system (whichever comes first)
The intent is that project specific variables should instead be stored in this file — in the current 1.5 branch this does degrade usability slightly, because there is no GUI support, but I believe that long-term this is a much better system, and 2.0 is likely to come with GUI support for this initialization procedure.
In other words, create a .textmate_init file in the project directory and let it contain e.g.:
export TM_LATEX_MASTER=master.tex
And then just forget about the project variables settable via the project drawer -- this of course starting with next build, unless you have a checkout of the Support directory.
Comments on this new system are of course welcome, as I am not fully decided on it yet, but I think it is the way to go, especially seeing how I do not want to rely on tmproj files for 2.0.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 5/6/2006, at 16:23, Eric Coleman wrote:
I like the project files, and that it keeps references & variables, HOWEVER, the issue is that it keeps track of window position and open files, so every time I do a commit the file is always modified.
If those were stored somewhere else it would be much easier to maintain..
And the essence of my letter was that you do not need to store the variables in the project file, and thus, can omit the project file from version control.
-
Allan Odgaard -
Daniel Harple -
Eric Coleman -
Michael Sheets -
Ollivier Robert