One of the original goals of the "pure-data" common source code repository was to be able to easily find Pd code. I think that now that there is a lot more development activity, I think that this no longer makes sense as a technique for cataloging code. I think that a wiki page on puredata.info would make a lot more sense, or perhaps other things.
Now people are starting to use svn:externals. I support the goal of findability; I do not think that svn:externals is the best way to do that. I think svn:externals is a tool for very specific cases. The pdmtl svn:externals was already causing problems because it uses a non-official TLS cert. This can break autobuilds, for example, and cause lots of headaches and support requests. I don't know of any other project that uses svn with svn:externals as a method for cataloging code.
So before we fill up the pure-data SVN with svn:externals links, I think we should make it clear what they are good for.
.hc
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic
On Fri, 20 Jun 2008, Hans-Christoph Steiner wrote:
Now people are starting to use svn:externals. I support the goal of findability; I do not think that svn:externals is the best way to do that. I think svn:externals is a tool for very specific cases.
Since then I realised that svn:externals is indeed a not-so-good idea. Today I removed my svn:externals link and switched to a regular copy using svn import.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Fri, 20 Jun 2008, Hans-Christoph Steiner wrote:
Now people are starting to use svn:externals. I support the goal of findability; I do not think that svn:externals is the best way to do that. I think svn:externals is a tool for very specific cases.
Since then I realised that svn:externals is indeed a not-so-good idea. Today I removed my svn:externals link and switched to a regular copy using svn import.
could you elaborate on why you now find that svn:externals are a not-so-good idea?
fgmasdr IOhannes
On Tue, 8 Jul 2008, IOhannes m zmoelnig wrote:
Since then I realised that svn:externals is indeed a not-so-good idea. Today I removed my svn:externals link and switched to a regular copy using svn import.
could you elaborate on why you now find that svn:externals are a not-so-good idea?
Because what if someone wants to make a branch out of all of the stuff in pd/externals ... then pd/externals/gridflow won't be branched, and that person won't be able to patch it. Well, there are already branches like that, and the same applies to tags. I thought that this is what Hans wanted me to understand but he didn't explain it. In any case, this is what I eventually understood from his original comment on svn:externals.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jul 8, 2008, at 3:25 PM, Mathieu Bouchard wrote:
On Tue, 8 Jul 2008, IOhannes m zmoelnig wrote:
Since then I realised that svn:externals is indeed a not-so-good idea. Today I removed my svn:externals link and switched to a regular copy using svn import.
could you elaborate on why you now find that svn:externals are a not-so-good idea?
Because what if someone wants to make a branch out of all of the stuff in pd/externals ... then pd/externals/gridflow won't be branched, and that person won't be able to patch it. Well, there are already branches like that, and the same applies to tags. I thought that this is what Hans wanted me to understand but he didn't explain it. In any case, this is what I eventually understood from his original comment on svn:externals.
That's a good reason, but I didn't realize it before. Thanks for pointing it out. Also, using svn:externals means that to do operations on source, all of the repositories have to be working fine in order for it to work. For example, on svn:externals link had a invalid certificate, causing an error which broke the auto-build. Ok, so you can accept the cert permanently. But since it was a self- generated cert, there is a good chance of it being regenerated.
This adds a source of problems without a whole lot of benefit, IMHO.
.hc
------------------------------------------------------------------------ ----
There is no way to peace, peace is the way. -A.J. Muste
On Wed, 9 Jul 2008, Hans-Christoph Steiner wrote:
On Jul 8, 2008, at 3:25 PM, Mathieu Bouchard wrote:
Because what if someone wants to make a branch out of all of the stuff in pd/externals ... then pd/externals/gridflow won't be branched, and that person won't be able to patch it. Well, there are already branches like that, and the same applies to tags. I thought that this is what Hans wanted me to understand but he didn't explain it. In any case, this is what I eventually understood from his original comment on svn:externals.
That's a good reason, but I didn't realize it before.
Ok, I really thought that this was THE reason you had in mind.
all of the repositories have to be working fine in order for it to work. For example, on svn:externals link had a invalid certificate, causing an error which broke the auto-build. Ok, so you can accept the cert permanently.
That's a small thing in comparison, because you can get it fixed quickly, whereas the only realistic thing to do with making a branch over multiple repositories is to first copy the other repositories into your home one, unless you do have accounts on all of them... and if you do, then you have to branch on all repositories separately, all of the time. Branches aren't added that often, but tags are in the exact same situation.
But since it was a self-generated cert, there is a good chance of it being regenerated.
I don't see why this would be happening any more often than a non-self-generated cert... Anyway, gridflow.ca also uses a self-generated cert, and yet I heard nothing about it. (What happened?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jul 9, 2008, at 1:26 AM, Mathieu Bouchard wrote:
On Wed, 9 Jul 2008, Hans-Christoph Steiner wrote:
On Jul 8, 2008, at 3:25 PM, Mathieu Bouchard wrote:
Because what if someone wants to make a branch out of all of the stuff in pd/externals ... then pd/externals/gridflow won't be branched, and that person won't be able to patch it. Well, there are already branches like that, and the same applies to tags. I thought that this is what Hans wanted me to understand but he didn't explain it. In any case, this is what I eventually understood from his original comment on svn:externals.
That's a good reason, but I didn't realize it before.
Ok, I really thought that this was THE reason you had in mind.
all of the repositories have to be working fine in order for it to work. For example, on svn:externals link had a invalid certificate, causing an error which broke the auto-build. Ok, so you can accept the cert permanently.
That's a small thing in comparison, because you can get it fixed quickly, whereas the only realistic thing to do with making a branch over multiple repositories is to first copy the other repositories into your home one, unless you do have accounts on all of them... and if you do, then you have to branch on all repositories separately, all of the time. Branches aren't added that often, but tags are in the exact same situation.
But since it was a self-generated cert, there is a good chance of it being regenerated.
I don't see why this would be happening any more often than a non- self-generated cert... Anyway, gridflow.ca also uses a self- generated cert, and yet I heard nothing about it. (What happened?)
Self-generated certs often have short expiration times. Also, people using self-generating certs often don't keep them up to date once they expire.
But really, I think we don't know all of the possible problems. If we introduce new tools that can affect all devs, like svn:externals, then someone needs to take responsibility for fixing things that it breaks. If not, then that tool just becomes a bigger burden, rather than making things more efficient.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
------------------------------------------------------------------------ ----
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard