On 9/4/2006, at 7:45, Quinn Comendant wrote:
[...] Are you implying that using svn to merge updates is NOT recommended?
For people who know what they are doing, I am not discouraging it.
The advantage of /Library is that one can rm -rf /Library/… w/o hesitation (believe me, this has been the answer to _many_ support questions) and that one will never get a svn merge conflict (which many users are not able to handle).
The advance of ~/Library is having svn be able to merge differences better than TM does. E.g. change a key equivalent in a bundle item, and svn still merges the customized version with changes done to the file. But it may lead to merge conflicts, so one should be prepared to handle these!
People who contribute to the svn repository will likely want at least the bundle they are maintaining (or submitting patches for) in ~/ Library.
So it boils down to using ~/Library has an advantage in getting svn’s merge, but with that comes potential problems, where /Library is 100% hassle free (but you lose the svn merge).
Surely TM will someday have functionality to ease merging built in. Any hints you can give to keep us from wandering down a path of deprecation?
The thing I have in mind is to let the bundle editor indicate when a customized version has a default version updated after the user modified it (and then allow the user to see the difference/revert to the default) -- I may also store only the modified properties of the bundle item in ~/Library (a property being either name, tab trigger, scope selector, actual content, input/output/save option for comments, etc.), which will cause only that property to override the default, rather than all properties of the bundle item.
As for “wandering down a path of deprecation”, I do not have any plans of changing the disk layout. There are users both with and without svn checkouts in /Library or ~/Library, and I don’t foresee any potential deprecation here.