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 //

http://www.vade.info
abstrakt.vade.info

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

- 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://
http://www.cassiel.com

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.

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

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 //

http://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).

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 //
>
> http://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).
>

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://
http://www.cassiel.com

What is the advantage of the UFS disk image route over text doc route?

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 //

http://www.vade.info
abstrakt.vade.info

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*
>
>
>
>
>
>
>

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