Forums > MaxMSP

git and max.

June 15, 2008 | 8:48 pm

A quick plug for git if you’re a Max developer.

I’ve been using the open-source distributed source control system git to manage my Max programming and it’s been a total winner for me, even though I’m working on my own.

Knowing that I’m a few keystrokes away from the last few good states of my system allows me to take all sorts of risks that I’d never take otherwise.

I only ever use git init, add, commit and checkout commands but it’s still incredibly powerful. Check it out if you’re doing serious development.

(Of course, I make offsite backups too :-D)


June 15, 2008 | 9:16 pm

personally, i’ve been using SVN hosted at Google Code…
i totally agree that using some form of source control is a very very good idea. it prevents the problems that arise when you break something in a patch while modifying it…. you can just look at an earlier version of it.
it’s also a nice way to keep a log of the work you do on a project. (makes me feel accomplished when i see 60+ updates for a project of mine)


June 15, 2008 | 10:02 pm

i’m currently using filehamster for windows.
its not a full blown svn solution, just an automated revisioning system.
very useful.
before i used "backup revision file" , it only saves something like 15
revisions back.
still nice to have on a diskonkey.

http://www.donationcoder.com/Forums/bb/index.php?topic=6564.msg45991

i’ll check git, but looks like an overkill, i saw the videocast were linus
presnted it, "an ego control system for open source developers".

On Mon, Jun 16, 2008 at 12:17 AM, thezer0ist

wrote:

>
> personally, i’ve been using SVN hosted at Google Code…
> i totally agree that using some form of source control is a very very good
> idea. it prevents the problems that arise when you break something in a
> patch while modifying it…. you can just look at an earlier version of it.
> it’s also a nice way to keep a log of the work you do on a project. (makes
> me feel accomplished when i see 60+ updates for a project of mine)
>


June 16, 2008 | 3:10 am

Thanks for the tip, Tom. I’ve been to implement something like this for awhile, but I’m pretty clueless on how these things work. I did manage to find a good noob guide for git here:
http://cworth.org/hgbook-git/tour/
any pointers on using it with Max?
cheers,
Jim


February 25, 2009 | 11:17 pm

Good stuff!

I recently posted a couple of guides for getting started using git for max projects (with github)

http://www.basementhum.com/2009/02/version-control-and-maxmsp-part-1.html

http://www.basementhum.com/2009/02/version-control-and-maxmsp-part-2.html

Next i’m hoping to find a sensible way to intelligently resolve conflicts in max’s JSON files.

Here’s the scenario that causes a problem for the default diff/merge mechanism git uses:

There’s an origin patch. Two users make parallel, but different edits to the patch; they both add a different comment box and type something into it. One of those users tries to merge the other’s changes into his repository.

Git can’t differentiate between the two comment boxes that have been added to the different versions. Instead it sees them as a single box with conflicts on the lines that describe diverging properties (text and boundary box coordinates). Of course the desired behaviour is that both comment boxes are incorporated into the merged file, and that no conflict is raised.

I think the solution might have to do with creating a custom merge(and or diff) driver for git that honours JSON structure. Javascript routines that do something similar are floating around, lie this one: http://tlrobinson.net/projects/js/jsondiff/.

It may also be necessary to enrich the id attributes of maxs objects to enable the merge routine to be able to reliably identify independent objects. Perhaps a pre-commit hook to a script could be added, that appends a timestamp after each object id (max leaves this kind of data intact when you re-save)–then the merge driver would inspect these id’s to determine whether or not to treat objects in parallel edits as identical, or separate.

If anyone has any thoughts, clues, suggestions about how to approach this, please let me know! Thanks. (apologies for cross posting to CDM too)


February 25, 2009 | 11:41 pm

I’m an SVN guy myself, I use Beanstalk. In 5.06 there is a new feature which can help with certain aspects of version control, I dunno if it will help your exact situation though.

You can send a new message to Max like this (or put it in an init file):
;max sortpatcherdictonsave 1

This makes it so that the JSON files that are used by Max for saving patches will keep the dictionary in the same order (alphabetized) every time you save. If you are keeping your patches in version control then this should make your diffs a lot more usable.

-A


February 26, 2009 | 9:04 am

"You can send a new message to Max like this (or put it in an init file):
;max sortpatcherdictonsave 1"

Thanks, that’ll certainly be useful. If i come across a way to intelligently handle diffing/merging of max objects in a scm i’ll post back.


March 3, 2009 | 12:43 am
Andrew Pask wrote on Wed, 25 February 2009 15:41

You can send a new message to Max like this (or put it in an init file):
;max sortpatcherdictonsave 1

This makes it so that the JSON files that are used by Max for saving patches will keep the dictionary in the same order (alphabetized) every time you save.

Every time I open Max? Or once?

mz

(Edit: nevermind. I figured out init files.)


May 27, 2013 | 3:50 pm

MZED, you may have figured out init files, but I’m still having trouble with them! Can anyone explain what they are and where they go?

Like everyone else on this thread, I’m using git, and I want to make sure my objects are sorted. Where should I put the sortpatcherdictonsave command to make sure it’s always executed?


May 27, 2013 | 5:59 pm

On OSX, the location should be either ~/Documents/Max/Packages/MyPackage/init/my-init.txt
or /Applications/Max 6.1/Cycling ’74/init/my-init.txt

my-init.txt should contain the line:

max sortpatcherdictonsave 1;

mz


May 27, 2013 | 6:01 pm

Sweet — thanks!


Viewing 11 posts - 1 through 11 (of 11 total)