Uh-oh!
As recommended, I've svn co'ed the bundles into my ~/Library TM directory in anticipation of using svn to merge updates into my custom stuff (bundle items).
However, I already *have* tons of custom stuff, so I tried merging my old stuff into the svn working directory using rsync -au. I followed this with some diff-ing to merge the language files and other conflicts. The only stuff I didn't merge were all the UUIDs.
And as you can guess, some of my old stuff has reverted back to the originals. Some stuff isn't showing up in the bundle editor (for example, both files exist: "PHP if( ).plist" and "if .. (if).plist", but the latter file is not available.
Any suggestions how to cleanly merge my old stuff into the svn co? Any way to completely reset all UUIDs? (I've already tried deleting the bundle Info.plist files, but the missing stuff doesn't appear...just everything goes out of order.)
Q
On 8/4/2006, at 3:40, Quinn Comendant wrote:
As recommended, I've svn co'ed the bundles into my ~/Library TM directory
The official recommendation is actually to checkout to /Library :p
in anticipation of using svn to merge updates into my custom stuff (bundle items).
I assume ‘recommendation’ then refers to one of the suggestions in the recent “how do you manage customizations”-thread!?!
However, I already *have* tons of custom stuff, so I tried merging my old stuff into the svn working directory using rsync -au. I followed this with some diff-ing to merge the language files and other conflicts.
rsync will not work, because when TM saves a new file, it uses a filename based on the name of the item. But when later updating the file, it preserves the filename.
This means that a lot of the default bundle items have older names on- disk, but when you customize one, it will get an updated name in ~/ Library. So the filenames will not (always) be the same.
[...] Some stuff isn't showing up in the bundle editor (for example, both files exist: "PHP if( ).plist" and "if .. (if).plist", but the latter file is not available.
Because they have the same UUID. That’s the only thing TM cares about.
Any suggestions how to cleanly merge my old stuff into the svn co?
It’s not straight-forward. You would need to generate a map of UUID => filename from scanning all the default bundles.
Then iterate over your custom stuff, lookup the UUID in this map, and rename it to that filename. First then, will you be able to use rsync.
So the essence is that your custom stuff do not have the original filenames, so they must be renamed to take the place of the files in svn, and the original filename can be found by checking the UUID of the item, and finding out which original file has that UUID.
[...] (I've already tried deleting the bundle Info.plist files, but the missing stuff doesn't appear...just everything goes out of order.)
The Info.plist is only used to set the ordering of items (and by marking default items as deleted, as they can’t be removed from disk). So in practice this file plays no vital role at all.
On Sun, 9 Apr 2006 04:09:44 +0200, Allan Odgaard wrote:
The official recommendation is actually to checkout to /Library :p
Ok, ok, you're right. ;P
I assume 'recommendation' then refers to one of the suggestions in the recent "how do you manage customizations"-thread!?!
Yeah, I don't know where I got that crazy idea. ;P
I was using /Library for the cutting-edge bundles, but then realized that the only newly updated things I could access where those I hadn't already modified.
Are you implying that using svn to merge updates is NOT recommended?
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?
Thanks for the UUID explanation... I'll see about writing a script to ease the process.
Q
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.
-
Allan Odgaard -
Quinn Comendant