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
    • 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|
    • 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.