Eric Skogen wrote:

Frank Barknecht wrote:

lose versioning control on pd patches. CVS can track ASCII changes, but IIRC cannot do anything with binaries save for archiving them (no merge, diff.. etc).

which is exactly what we want. have you ever tried to merge 2 pd-patches ?

mfg.asd.r IOhannes

Hallo, B. Bogart hat gesagt: // B. Bogart wrote:

I did hear that subversion has a binary diff for binary deltas I don't know the details though.

Ah, subversion. If we someday leave SF and move to IEM, I would stongly vote for using Subversion instead of CVS. It has many advantages in regard to moving files and handling binary/diff stuff and is really easy to use. I'm playing around with it a lot currently, but didn't try merging Pd-patches yet. Will do after LAConf2.

Ciao

On Mon, 26 Apr 2004, IOhannes m zmoelnig wrote:

...

Ah, subversion. If we someday leave SF and move to IEM, I would stongly vote for using Subversion instead of CVS. It has many

yes, yes, me too. my only fear was, that the pd-community would not accept another versioning system.

I share this concern, on the other hand, somtimes a move motivates people. Now that we have some experience we can probably learn from errors made on the sf CVS and make it better, with a better version control system.

Maybe we start with moving some of the projects to subversion, instead of all of them (like the iemlibs, for example :)

Guenter

and now, there seem to be good subversion-clients for windows and macOS.

On Mon, 26 Apr 2004, Frank Barknecht wrote:

Ah, subversion. If we someday leave SF and move to IEM, I would stongly vote for using Subversion instead of CVS. It has many advantages in regard to moving files and handling binary/diff stuff and is really easy to use. I'm playing around with it a lot currently, but didn't try merging Pd-patches yet. Will do after LAConf2.

Wow, if it can merge pd patches ... But I doubt that.

Guenter

Frank Barknecht wrote:

Hallo,

I wonder how I could test that reliably. I already tried to make some simple changes to Pd files like deleting objects. commiting the changes to a svn-repository, replacing the changed file with the previous version and and running update afterwards did work, so it seems. (Is this merging?) At least the patch was functional and was

no it is not. (but you are patching the pd file, which works ;-))

1. create a pd-file 2. make a backup-copy 3. change the original pd-file 4. commit it to the svn/cvs 5. replace the (changed) original file with the backup. 6. change the backup copy 7. update from the cvs

this should produce a merge.

mfg.as.dr IOhannes

Frank Barknecht wrote:

for every versioning software that tries to merge Pd patches. Probably only Pd can be used to do this with copy/paste.

right. if Pd is the only software (including humans!) that can handle (merging of) Pd-patches correctly, then i consider .pd-files as binary.

mfg.as.dr IOhannes

On Tue, 27 Apr 2004, Frank Barknecht wrote:

...

Wow, if it can merge pd patches ... But I doubt that.

I wonder how I could test that reliably. I already tried to make some simple changes to Pd files like deleting objects. commiting the changes to a svn-repository, replacing the changed file with the previous version and and running update afterwards did work, so it seems. (Is this merging?) At least the patch was functional and was missing the previously deleted objects.

merging means that you have a file changed in your sandbox, but the same file got changed in CVS. Upon next update the changes that happened in CVS are merged with the changes you did.

This can't work for pd patches by definition, as the connections are defined by the position of the object. A pd merger would have to be a pretty intelligent program, that has to know exactly how pd patches work. Unless subversion is designed to merge pd patches, it can't do it.

I don't know, maybe it is possible to write external merger scripts or programs for SV (which would be an interesting feature).

Guenter

On Tuesday, Apr 27, 2004, at 08:39 America/New_York, Eric Skogen wrote:

Frank Barknecht wrote:

...

Hallo,

today I wanted to commit some rradical patch changes to CVS, when cvs bailed out with errors like: confused about file rrad.minipli.pd -- ignoring

I vaguely remember, that Pd files maybe should be stored as binary in CVS. Reading a bit around about this I found, that it is possible to make *.pd files be always treated as binary by adding them to the "cvswrappers" file. So maybe some CVS guru can comment, if this would make sense?

Ciao

this is a total guess.. maybe it doesn't like the multiple dots? (rrad.minipli.pd vs rrad_minipli.pd)

CVS is good about file names, I use all kinds of chars in filenames of things checked into my own CVS and I've never had a problem.

i would say patches should handled just like any other source code, since they are plain text. by switching to a binary format, you would lose versioning control on pd patches. CVS can track ASCII changes, but IIRC cannot do anything with binaries save for archiving them (no merge, diff.. etc).

We could add .pd files to the cvswrappers with the -kb tag, which is the only specific 'binary' handling that CVS does server-side AFAIK. All -kb does is prevent keyword expansion ($Revision $, $Id $, etc.). But I use those so I'd like to keep it in there. I am pretty sure that preventing merges happens on the client-side, since the actual merge happens on the client side.

As for merging .pd files, the merge algorithm would have to understand object numbering and be able to change the object numbers in connect messages, as well as probably other things. I have always dreamed of a graphical diff for Pd, merging would probably be a simple extension to that work.

.hc

________________________________________________________________________ ____

Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams