[TxMt] merging UUIDs

[Allan Odgaard]

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.