git and max.
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)
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)
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)
>
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
Good stuff!
I recently posted a couple of guides for getting started using git for max projects (with github)
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)
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
"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.
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.)
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?
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
Sweet -- thanks!
Where can I find the "my-init.txt" within Max7?
FWIW, sortpatcherdictonsave defaults to 1 in Max 6.1.10 and in Max 7.
If you want an init file for some other reason, you can just make one and place it in the Max.app bundle. Just right click on the app, 'show package contents' and navigate to /Applications/Max.app/Contents/Resources/C74/init
-Ben
It might be worth mentioning that if you put an init file inside the Max app package, it will be lost next time you upgrade to a newer incremental version of Max.
Also, modifying the Max app package requires admin privileges and is then applied to all users. Neither of these may be a limitation for many users, but on installations at, say, university labs it might not be an option.
We were all supposed to be excited when Mac OS became a "professional," Unix-based OS, were we not? -)
If you do have problems with modifying the app package, you could also create a 'Package' in ~/Documents/Max 7/Packages or /Users/Shared/Max 7/Packages, which can have an init folder.
-Ben