Using version control (SVN) with Max/MSP based patchers from OS X - loosing metadata ?


    Nov 29 2006 | 9:48 pm
    Hello
    Here is a random one.
    I am working on a fairly large patch (really set of patches) with another Max/MSP programmer, for various systems. In order to help maintain sanity, we have started to use SVN (Subversion) for a revision control system for our patchers.
    For certain (valid, but I dont want to go into it) reasons, some of our patchers do not have a file extension. When checking out patches from our repository, our patches loose their association with Max/MSP as their 'parent' app.
    This is an issue as we are using certain apple scripts to check that max is running, auto launch the app, and also using thispatcher scripting and ubumenu's to auto-load assets off of disk, and this gets fubar'ed without the associated metadata.
    When using mxb or mxt formatted patchers without their respective .mxb or .mxt extension, we loose our association and we cannot open the files by double clicking or opening max and saying file - open. If we use .mxt extension, we loose the icon and double clicking the patch wont open Max, but selecting open from Max will let it open,, if we use .mxb, we keep the icon and all works well.
    Have other people run into this? Is this an issue with how mime-types/ file-types and creators work on OS X with resources, and SVN stripping resource forks or .DS_Store files (or other magic hidden OS X FS related BS), or is this something with our SVN servers file system stipping the data, or a limitation of SVN itself? I searched and noticed that SVN way back when had issues with this, but that newer revisions supposedly fixed it. Is this a server side or client side issue?
    Apologies for this (mostly) off topic post, but im curious how people handle revision control when working with Max - and if anyone is working sucsessfuly with SVN+ Max/MSP
    We can try and re-formulate some things to use file types and extensions on our end, but it would save lots of hours and money if we can simply tell SVN to not strip any metadata.
    Thanks!
    v a d e //
    www.vade.info abstrakt.vade.info

    • Nov 29 2006 | 10:52 pm
      On Nov 29, 2006, at 4:48 PM, vade wrote: > Apologies for this (mostly) off topic post, but im curious how > people handle revision control when working with Max - and if > anyone is working sucsessfuly with SVN+ Max/MSP
      vade: Hopefully Tim Place will chime in on this one. We used SVN during the development of Hipno. He worked out all these issues.
      It's been a while, but I do remember that there were certain file types the server would mangle. The solution he came up with was to zip or stuff certain things in an archive before checking in. Kind of a pain, but it worked.
      Tim would have more specifics. --Nathan
      ----- Nathan Wolek nw@nathanwolek.com http://www.nathanwolek.com
    • Nov 29 2006 | 11:10 pm
      I've been using MacCVSClient for some years to source-control my Max code base (well, bases plural). Some comments:
      - MacCVSClient lets you associate filetype and creator codes with file extensions (and can also associate extensions with CVS encodings like -kb);
      - For complicated files, MacCVSClient can store using a combined data/ resource fork - it may be (although I haven't verified) that this will take care of files without extensions, assuming it encodes what we use to call BNDL resources, but my Inside Macintosh knowledge is rather rusty.
      Of course, in the latter case you lose "diff" functionality, but since Max patchers are stack based, that doesn't help much in the first place. In any case, I store all my patcher files as .mxt text, with max2/TEXT as creator/type.
      CVS certainly has its limitations, but last time I checked, SVN didn't have an implemented mechanism for storing metadata for OS X files, although there were proposals for doing so. (I had a look at darcs as well, and came to a similar conclusion.)
      -- N.
      nick rothwell -- composition, systems, performance -- http:// www.cassiel.com
    • Nov 30 2006 | 8:03 am
      The way we do it for Jamoma (www.jamoma.org) is that all Max patches are saved as text files, using the .mxt extension. When saved in text format it is a lot easier to diff than in binary format. Earlier on we have used custom .mod and .alg file endings for modules and algorithms respectively, but these cause some problems that have made us decide to move away from them for the next version (0.4).
      Universal Binary externals are really packages. If we were introducing them to the repository as is, SVN would start adding svn-related stuff inside of them, breaking their functionalities. For this reason compiled versions of externals for Mac are committed to the repository as a zipped file.
      SVN, hosted at sourceforge, works really well for us, and was set up by Tim.
      Best, Trond
      Nathan Wolek wrote: >> Apologies for this (mostly) off topic post, but im curious how people >> handle revision control when working with Max - and if anyone is >> working sucsessfuly with SVN+ Max/MSP > > vade: > Hopefully Tim Place will chime in on this one. We used SVN during the > development of Hipno. He worked out all these issues. > > It's been a while, but I do remember that there were certain file > types the server would mangle. The solution he came up with was to > zip or stuff certain things in an archive before checking in. Kind of > a pain, but it worked. > > Tim would have more specifics.
    • Nov 30 2006 | 11:24 am
      On 30-Nov-2006, at 0:10, Nick Rothwell wrote: > CVS certainly has its limitations, but last time I checked, SVN > didn't have an implemented mechanism for storing metadata for OS X > files, although there were proposals for doing so.
      I pored through the SVN development lists quite recently to try to find out what the story was on HFS+ support (metadata, etc.).
      The SVN community is, by and large, frankly hostile to the notion of support for anything that isn't UFS. From the point of view of a Mac user, this just plain sucks. It also sucks for Windows users, just not so hard (FAT32 & Co. don't provide as much meta-data that needs to be maintained).
      Even more disappointing is the fact that the developers of SVN front- ends for Mac OS haven't gone the extra mile to transparently handle Mac meta-data. There are several approaches to this, the most common one is to zip/unzip. AFAICT, neither eSvn, nor iSVN, nor SvnX, nor ZigVersion automate this.
      I would have been interested to know what Tim set up to get SVN more Mac-friendly, but in the end the project I am working on decided to stick with the devil that works (CVS).
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +--> Litter Power & Litter Bundle for Jitter Universal Binaries on the way iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Nov 30 2006 | 4:31 pm
      Thank you all for the input - its most helpful. In my research I also noted a pretty heavy lack of transparent meta-data support for SVN. Im pretty surprised by this personally. I may have to either go the zip route or try an alternative CVS system. I had high hopes for using svnX to manage things. Perhaps I ought to just learn from the command line anyway.
      Ill report back if I have any breakthroughs, and would also love to know what Tim has done. I have an existing svn repository at sourceforge. I should try using that versus my clients. Perhaps here is a revision or configuration issue.
      Thanks again.
      v a d e //
      www.vade.info abstrakt.vade.info
      On Nov 30, 2006, at 6:24 AM, Peter Castine wrote:
      > > I would have been interested to know what Tim set up to get SVN > more Mac-friendly, but in the end the project I am working on > decided to stick with the devil that works (CVS).
    • Dec 03 2006 | 9:00 am
      I had an absolutely brilliant suggestion from a gentleman from another forum (Arstechnica)
      The solution seems to be to work from a UFS formatted disk image. This forces OS X to create ._AppleDouble formatted resource fork streams on partitions that do not support resource forks or xattr metadata, essentially creating another *real* file that contains the resource fork information.
      When committing to SVN, make sure to add all of your ._ files to be committed. When you check them out again (to a UFS formatted disk if you dont want to loose resource forks again), you will magically have your resource forks, icons and application/document mapping.
      This seems to actually work in my testing, and does not require zipping or any other work around.
      I hope you will all find this helpful. Its a bit tricky, but looks very promising as a complete solution. Now to just get used to SVN!
      Yay!
      On Nov 30, 2006, at 11:31 AM, vade wrote:
      > Thank you all for the input - its most helpful. In my research I > also noted a pretty heavy lack of transparent meta-data support for > SVN. Im pretty surprised by this personally. I may have to either > go the zip route or try an alternative CVS system. I had high hopes > for using svnX to manage things. Perhaps I ought to just learn from > the command line anyway. > > Ill report back if I have any breakthroughs, and would also love to > know what Tim has done. I have an existing svn repository at > sourceforge. I should try using that versus my clients. Perhaps > here is a revision or configuration issue. > > Thanks again. > > > v a d e // > > www.vade.info > abstrakt.vade.info > > > > On Nov 30, 2006, at 6:24 AM, Peter Castine wrote: > >> >> I would have been interested to know what Tim set up to get SVN >> more Mac-friendly, but in the end the project I am working on >> decided to stick with the devil that works (CVS). >
    • Dec 03 2006 | 11:48 am
      > The solution seems to be to work from a UFS formatted disk image. > This forces OS X to create ._AppleDouble formatted resource fork > streams on partitions that do not support resource forks or xattr > metadata, essentially creating another *real* file that contains > the resource fork information.
      I did think about that a while ago; well, actually, a slightly more complicated version: to do version control on a Linux directory tree which has been mounted as a network volume. But if the UFS technique works on the Mac itself that sounds promising.
      -- N.
      nick rothwell -- composition, systems, performance -- http:// www.cassiel.com
    • Dec 16 2006 | 2:13 am
      This is a very fascinating discussion. I'd love to hear whether any of you folks got Vade's approach to work. I have been playing around with svn for other development projects and it never occurred to me to both version AND the metadata problems for Max/MSP.
      What is the advantage of the UFS disk image route over text doc route?
    • Dec 16 2006 | 2:37 am
      The text doc route still my not fully restore metadata - at least with my tests it certainly didnt.
      Ive been trying to use the UFS disk image, but with my GUI client (SVN-X), I get errors occasionally when checking in and checking out that certain ._AppleDouble files dont exist, which really, you know, defeats the purpose.
      Ive basically given up with SVN. Id love someone else to give it a shot - im pretty bad with CVS type stuff anyway, im certain someone can get it working properly.
      On Dec 15, 2006, at 9:13 PM, Matthew Griffin wrote:
      > > This is a very fascinating discussion. I'd love to hear whether any > of you folks got Vade's approach to work. I have been playing > around with svn for other development projects and it never > occurred to me to both version AND the metadata problems for Max/MSP. > > What is the advantage of the UFS disk image route over text doc route? >
      v a d e //
      www.vade.info abstrakt.vade.info
    • Dec 16 2006 | 10:05 pm
      any resources/guides for version control that work under windows will be apprciated. the wiipedia article is a messs
      On 12/16/06, vade wrote: > > The text doc route still my not fully restore metadata - at least with my > tests it certainly didnt. > Ive been *trying* to use the UFS disk image, but with my GUI client > (SVN-X), I get errors occasionally when checking in and checking out that > certain ._AppleDouble files dont exist, which really, you know, defeats the > purpose. > > Ive basically given up with SVN. Id love someone else to give it a shot - > im pretty bad with CVS type stuff anyway, im certain someone can get it > working properly. > > > On Dec 15, 2006, at 9:13 PM, Matthew Griffin wrote: > > > This is a very fascinating discussion. I'd love to hear whether any of you > folks got Vade's approach to work. I have been playing around with svn for > other development projects and it never occurred to me to both version AND > the metadata problems for Max/MSP. > > What is the advantage of the UFS disk image route over text doc route? > > > > *v a d e //* > > *www.vade.info* > *abstrakt.vade.info* > > > > > > >
    • Dec 17 2006 | 12:21 pm
      On 16 Dec 2006, at 22:05, yair reshef wrote:
      > any resources/guides for version control that work under windows > will be apprciated. > the wiipedia article is a messs
      No news there then.
      The GNU CVS client I occasionally use under Windows 98 is a bit of a mess also; on more recent Windowses you might have a go with the command-line CVS running under Cygwin?
      -- N.