Hey,
There was gung-ho talk back at PdCon about switching to SVN. It's been quiet recently, any word on that? :)
.hc
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
I know SVN better myself - since I use it for the rest of my work.. -David
On 10/22/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey,
There was gung-ho talk back at PdCon about switching to SVN. It's been quiet recently, any word on that? :)
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I don't want to sound like I'm just trumpeting the latest hype, but someone is going to say it, so it may as well be me:
Considering the highly distributed nature of Pd development (lots of people with dev access working on different, independent parts), I really think a distributed system like Git would be appropriate to the Pd project.
Instead of committing your changes to one big repo, you just work on your own, developing features, and you tell people when you've done something cool, and they are free to copy it from you and merge it into their version (or not). It takes the politics right out of things. Everyone is in charge of their own work, and no one else's.
I've been playing with it a lot lately and it's really got some advantages in how it deals with team work. There are also lots of scripts to help making a transition from CVS.
In any case it's not my decision, but I highly recommend checking it out. It works on Windows under MingW as well as OS X and Linux.
http://git.or.cz/ http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
Steve
On 10/22/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey,
There was gung-ho talk back at PdCon about switching to SVN. It's been quiet recently, any word on that? :)
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo!
I don't know much about git, but what I have read this would defenitely be an option. Then also synching developer and millers version should be easier if I understood that correctly ?
What do the others think ?
LG Georg
I don't know much about git, but what I have read this would defenitely be an option. Then also synching developer and millers version should be easier if I understood that correctly ?
What do the others think ?
i recently started using git for nova, it is really an extremely powerful tool, compared to cvs/svn ... especially for nonlinear distributed development it is far more suited than cvs/svn ... also maintaining parallel branches is way easier ...
however i am not sure, if it is the right tool for the pd developer community, which seems to be quite conservative in terms of which tools are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...
best, tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Happiness is a byproduct of function, purpose, and conflict; those who seek happiness for itself seek victory without war. William S. Burroughs
are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...
You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.
Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.
Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.
I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".
Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.
I won't try any more to push the idea, but I think it's worth considering.
Steve
On Oct 23, 2007, at 2:41 PM, Stephen Sinclair wrote:
are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...
You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.
Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.
Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.
I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".
Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.
I won't try any more to push the idea, but I think it's worth considering.
Actually, it would be good if you did push the idea. :D I think if we aren't switching to SVN, we really should consider a distributed system. I am just not sure which one is the best one for the Pd community. While Linus' personality is funny, his ideas about software usability are what make me think there are better systems than git.
From what I see, Git is good for someone who's immersed in it, therefore the extra complexity is beneficial. Pd committers don't do it that often, and are rarely immersed in coding everyday. That says that we should use something that is really easy to learn, setup, and administer, even if that means it might be less efficient for more advanced tasks.
For example, GNU Arch says on the first page (http://www.gnu.org/ software/gnu-arch/) that "GNU arch has some features that make it particularly useful for public free software projects: it's easy to learn; it's inexpensive and easy to administer". Git (http:// git.or.cz/) repeatedly mentions "speed and efficiency".
.hc
Steve
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
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.
Actually, it would be good if you did push the idea. :D I think if we aren't switching to SVN, we really should consider a distributed system. I am just not sure which one is the best one for the Pd community. While Linus' personality is funny, his ideas about software usability are what make me think there are better systems than git.
From what I see, Git is good for someone who's immersed in it, therefore the extra complexity is beneficial. Pd committers don't do it that often, and are rarely immersed in coding everyday. That says that we should use something that is really easy to learn, setup, and administer, even if that means it might be less efficient for more advanced tasks.
For example, GNU Arch says on the first page (http://www.gnu.org/ software/gnu-arch/) that "GNU arch has some features that make it particularly useful for public free software projects: it's easy to learn; it's inexpensive and easy to administer". Git (http:// git.or.cz/) repeatedly mentions "speed and efficiency".
Sigh, anything is better than CVS... so I won't complain too loudly if we go with something other than SVN. But considering how long it's taking to go to SVN, which everyone agrees with, I'm worried we'll just get bogged down in discussion of the myriad options.
Many of SVN's deficiencies are being addressed in the very-very-soon upcoming 1.5 update, which includes vastly improved merging to compete with Git.
Also, since SVN has such wide adoption, it has really excellent client tools. I use SCPlugin, which integrates SVN with the Mac OS X Finder, along with TextMate's absolutely incredible SVN bundle. Windows users have access to the amazing TortoiseSVN, which offers the best integration I've seen.
Anyways, here's to a swift death for CVS. Cheers Luke
Also, I believe IOhannes already did a lot of work to get SVN running; last I saw we were basically just waiting for everyone else to be ready? I'll let him confirm but it would be a shame to have wasted his time : ). Info on SVN 1.5 is here: http://subversion.tigris.org/svn_1.5_releasenotes.html
On 10/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote:
Actually, it would be good if you did push the idea. :D I think if
we aren't switching to SVN, we really should consider a distributed system. I am just not sure which one is the best one for the Pd community. While Linus' personality is funny, his ideas about software usability are what make me think there are better systems than git.
From what I see, Git is good for someone who's immersed in it, therefore the extra complexity is beneficial. Pd committers don't do it that often, and are rarely immersed in coding everyday. That says that we should use something that is really easy to learn, setup, and administer, even if that means it might be less efficient for more advanced tasks.
For example, GNU Arch says on the first page ( http://www.gnu.org/ software/gnu-arch/) that "GNU arch has some features that make it particularly useful for public free software projects: it's easy to learn; it's inexpensive and easy to administer". Git (http:// git.or.cz/) repeatedly mentions "speed and efficiency".
Sigh, anything is better than CVS... so I won't complain too loudly if we go with something other than SVN. But considering how long it's taking to go to SVN, which everyone agrees with, I'm worried we'll just get bogged down in discussion of the myriad options.
Many of SVN's deficiencies are being addressed in the very-very-soon upcoming 1.5 update, which includes vastly improved merging to compete with Git.
Also, since SVN has such wide adoption, it has really excellent client tools. I use SCPlugin, which integrates SVN with the Mac OS X Finder, along with TextMate's absolutely incredible SVN bundle. Windows users have access to the amazing TortoiseSVN, which offers the best integration I've seen.
Anyways, here's to a swift death for CVS. Cheers Luke
On Oct 23, 2007, at 3:44 PM, Luke Iannini (pd) wrote:
Actually, it would be good if you did push the idea. :D I think if we aren't switching to SVN, we really should consider a distributed system. I am just not sure which one is the best one for the Pd community. While Linus' personality is funny, his ideas about software usability are what make me think there are better systems than git.
From what I see, Git is good for someone who's immersed in it, therefore the extra complexity is beneficial. Pd committers don't do it that often, and are rarely immersed in coding everyday. That says that we should use something that is really easy to learn, setup, and administer, even if that means it might be less efficient for more advanced tasks.
For example, GNU Arch says on the first page ( http://www.gnu.org/ software/gnu-arch/) that "GNU arch has some features that make it particularly useful for public free software projects: it's easy to learn; it's inexpensive and easy to administer". Git (http:// git.or.cz/) repeatedly mentions "speed and efficiency".
Sigh, anything is better than CVS... so I won't complain too loudly if we go with something other than SVN. But considering how long it's taking to go to SVN, which everyone agrees with, I'm worried we'll just get bogged down in discussion of the myriad options.
Many of SVN's deficiencies are being addressed in the very-very- soon upcoming 1.5 update, which includes vastly improved merging to compete with Git.
Also, since SVN has such wide adoption, it has really excellent client tools. I use SCPlugin, which integrates SVN with the Mac OS X Finder, along with TextMate's absolutely incredible SVN bundle. Windows users have access to the amazing TortoiseSVN, which offers the best integration I've seen.
Anyways, here's to a swift death for CVS. Cheers Luke
I'm not ruling out SVN at all. You're point is another excellent thing to consider, especially for this project. In addition, git is written for Linux, and has only alpha support for Windows. That would be bad for Pd since Windows users download Pd more than all other platforms combined. I don't know about arch and darcs. We need more Windows users to contribute to Pd, so we don't want to put up any more barriers.
.hc
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
Actually, it would be good if you did push the idea. :D I think if
Okay then.. ;-) It's a good discussion anyway..
I think these are all very good arguments for / against svn and git.
I'll just note that I've briefly tested out the Windows git installer, and it is pretty nice. I did get an error during a "clone" operation at one point, which was solved by just doing the same thing on the command line.. (yes, strange, but as you said, alpha.)
Svn is obviously way better than CVS, but I don't really follow the arguments about how Pd is different from Linux. In fact, I see a lot of similarity between pd and Linux:
- a kernel that takes pretty intense "hacking skillz" to understand and efficiently improve - externals that add useful functionality (kernel modules) - satellite projects that make it usable (abstractions)
Honestly I think that the only reason git (or at least, distributed SCM) seems "weird" is because we're all so used to thinking in a centralized way. I'm not at all convinced that a "newbie" would find CVS or Svn somehow easier or more natural than git.
Most of the weird commands in git are intended for doing odd things like retroactively fixing a broken commit or to pull a particular branch from another user's public repo.
Most of the time, git is like this:
git-clone http://some-server/pd-extended.git -- make a local copy of the repo *work work work *... git-commit -m "my fantastic new changes" *work work work*... git-commit -m "more fantastic new changes" git-push (to my public server..)
Oh look there's been a nice update, and they've pulled my changes git-pull *work work work*...
etc.
I'm not claiming there would be no learning curve. But I think there are some advantages.
In any case, as I said previously, using SVN doesn't necessarily rule out being able to use git along with it for those who want to. There is a script, git-svn, which can be used to keep a local git repo in sync with a public Svn repo. So you'd work exactly as I described above, but instead of the git-push command, you'd use git-svn and your Svn repo would be your public repository.
(I haven't tested this much, so it would be worth "trying before buying.")
Of course then you're back to everyone potentially stepping on toes. The thing I like best about it so far, especially since I've only used it on very small projects, is that you can commit many changes before actually publishing them. So you can really think of commits as "semantic building blocks" instead of as "publishing". It separates these two ideas nicely.
Anyways.. hm, also keep in mind there are other distributed SCMs around. There's even one that is more Svn-oriented, called SVK (which I haven't used.) I admittedly only jumped on git because of how it is used for Linux, but also because I've noticed more and more projects taking an interest in it lately. Also I was very attracted to the fact that you can publish your repo on a regular old http server without requiring any kind of special apache module or installing anything. (Since I don't have access to install things on my web server.)
I researched it for quite some time before actually moving one of my projects to it, so I did consider things carefully. So far it's been quite a satisfying move.
Steve
Hallo, Stephen Sinclair hat gesagt: // Stephen Sinclair wrote:
Actually, it would be good if you did push the idea. :D I think if
Okay then.. ;-) It's a good discussion anyway..
I think these are all very good arguments for / against svn and git.
I believe the main argument for SVN is that it's offerend by Sourceforge and basically everone involved already knows her/his way around it. It would be the RCS that we could upgrade to with the least effort and thus a ahrd to beat effort/gain coefficient. From what I've heard that was also the bottom line of the Montreal discussion which I unfortunatly missed.
Ciao
Hallo!
actually publishing them. So you can really think of commits as "semantic building blocks" instead of as "publishing". It separates these two ideas nicely.
apropos: to the Montreal SVN discussion:
Didn't also Miller say, that he wants something like this ? (he also mentioned such a distributed system - don't rember if it was git)
LG Georg
Speaking from experience, having suffered several migrations to prcs from cvs, to svn from cvs, and to darcs from svn, in commercial projects, I have to say the only one that worked well, made sense, and was least painful was cvs-->svn, and I'd vote for that.
David
On 23 Oct 2007, at 19:41, Stephen Sinclair wrote:
are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...
You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.
Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.
Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.
I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".
Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.
I won't try any more to push the idea, but I think it's worth considering.
Steve
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
There are a couple key factors in this decision that seem to be getting confused with each other. I'm new to PD, but I've been using Git for over a year now with my own repositories. In various consulting projects over the last few years I've developed with CVS, SVN, Mercurial, Darcs, Arch and Bazaar-ng. There are a couple facets to the decision.
1) Distributed Development
The first, and I think most important, is the development model. Distributed development supports a different kind of collaboration, that I think is showing itself to be quite advantageous for open source software. It lets groups of people organize themselves, get a piece of code working, and then it can be shared with the world. Permissions and management of a central repository is no longer an issue. It doesn't exist. Instead Hans-Christoph, for example, would manage an official pd-extended branch that had the fully tested features, while everyone else could still share the latest and greatest stuff without having a centralized bottle-neck.
2) Personal development advantages
In git you have the whole repository locally. This takes more storage space, which is incredibly cheap, but saves LOTS of time. SVN can never merge as well as GIT because you don't have past versions of the repository to merge against. Additionally, with git you get local versioning, local branching, and tons of distributed back-ups of the repository. I'm always working on the train, for example, and with Git I can maintain a much better log of my development because I commit all the time without needing internet access. Branches in git, even for huge projects, are basically free. In space and time. This changes the way you develop. You can make a branch for any little idea you want to mess with or any tricky feature you are working on. It's quite easy to then merge these branches, share them with friends, update them from other's repositories etc. This is a level of power and control that you can not get with svn.
3) User Interface
Git was originally designed to function as a back-end suite that would support easy to use front-end utilities. That has changed over time, and it now includes a nice set of commands and tools that make it work just like you would expect. For sure Git doesn't have the GUI plugins like SVN or CVS and it will take some learning, but I think the benefits in the long term will far, far outweight the initial investment.
There is a Tk interface, GitK, which is incredibly useful to visually look at the history of a repository, merges, branches etc. There is also git-web, which lets you view the repository online. Git also lets you publish a repository just by copying a directory to an http accessible location. This means anyone can share their ideas, features, abstractions etc, without setting up a server, getting permission for a centralized location or anything. Also relevant to the user experience is speed. Git blows away all the other systems in terms of speed. It does everything faster, and you really notice this because it changes what you do. In some of the other systems, like Bazaar-ng, committing, pulling and pushing took so long I wouldn't do it that often, but with git it's all so cheap I do it every time I get a new unit test to pass.
4) Technical
Git writes the repository into a highly compressed format, and then it does not mess with the files. Append only is the standard operation, except for when you occasionally compress the whole thing, in which case it can verify sanity. It is also much cleaner to work with in terms of permissions and access, just because of the whole usage model. I've had many experiences with subversion where the repository had to be recovered because of permissions issues and/or corruption. This is very bad, especially since it is a centralized server that everyone is counting on. It takes a root user to go in and run "svnadmin recover", which in my opinion is a command that shouldn't need to exist in something as important as a source repository.
Keith Packard who runs the X.org project wrote a very good post detailing his research and opinions into source control. It's a bit old now, but worth the read: http://keithp.com/blog/Repository_Formats_Matter/index.html
Sorry for the long post, but this is something I have dealt with a lot recently. In my mind distributed versioning is the only proper way to run a modern open source project. PD is a great piece of software with a seemingly cool and diverse group of developers, which seems perfect for a decentralized model. Either way, I think the decision should be made first between a centralized or distributed versioning system, and then the decision can be simplified to figuring out compatibility, usability etc. It's great news that Git now runs on windows though, because I think it is far better than the others. To quote one of Hans-Christoph's recent signature lines:
Mistrust authority - promote decentralization. - the hacker ethic
:-)
Ciao, Jeff
David Plans Casal wrote:
Speaking from experience, having suffered several migrations to prcs from cvs, to svn from cvs, and to darcs from svn, in commercial projects, I have to say the only one that worked well, made sense, and was least painful was cvs-->svn, and I'd vote for that.
David
On 23 Oct 2007, at 19:41, Stephen Sinclair wrote:
are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...
You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.
Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.
Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.
I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".
Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.
I won't try any more to push the idea, but I think it's worth considering.
Steve
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Mistrust authority - promote decentralization. - the hacker ethic
In any case, if anyone wants to try it out, feel free to clone the git repository I made last night with git-cvsimport:
git-clone http://www.music.mcgill.ca/~sinclair/git/pd/pd.git
It'll be about 54MB of downloads, streaming strange SHA1 checksum numbers down your screen until it's done. When it has finished, try "git log" to see the history... Also try "git branch -r" to see the branches.
git-cvsimport can only import a single cvs module at a time. So I have a couple other repositories listed there:
git-clone http://www.music.mcgill.ca/~sinclair/git/pd/externals.git git-clone http://www.music.mcgill.ca/~sinclair/git/pd/abstractions.git
Steve
That still leaves me with questions about the interface of git. That blog post is interesting, but as he says in the first sentence, he is ignoring the interface. He then goes on to say:
The key detractors for Git was (and remains) the steep learning curve for the native Git interface; ameliorated for some users by alternate interfaces (such as Cogito), but not for core developers.
The most technically amazing system in the world is useless if people in question don't want to spend the extra effort to learn how to use it.
It sounds to me like the best system is SVN as the core repository, then people can use git if they want, and sync it to SVN. Miller currently does this with Git->CVS.
.hc
On Oct 24, 2007, at 8:39 AM, Jeff Rose wrote:
There are a couple key factors in this decision that seem to be getting confused with each other. I'm new to PD, but I've been using Git for over a year now with my own repositories. In various consulting projects over the last few years I've developed with CVS, SVN, Mercurial, Darcs, Arch and Bazaar-ng. There are a couple facets to the decision.
- Distributed Development
The first, and I think most important, is the development model. Distributed development supports a different kind of collaboration, that I think is showing itself to be quite advantageous for open source software. It lets groups of people organize themselves, get a piece of code working, and then it can be shared with the world. Permissions and management of a central repository is no longer an issue. It doesn't exist. Instead Hans-Christoph, for example, would manage an official pd-extended branch that had the fully tested features, while everyone else could still share the latest and greatest stuff without having a centralized bottle-neck.
- Personal development advantages
In git you have the whole repository locally. This takes more storage space, which is incredibly cheap, but saves LOTS of time. SVN can never merge as well as GIT because you don't have past versions of the repository to merge against. Additionally, with git you get local versioning, local branching, and tons of distributed back-ups of the repository. I'm always working on the train, for example, and with Git I can maintain a much better log of my development because I commit all the time without needing internet access. Branches in git, even for huge projects, are basically free. In space and time. This changes the way you develop. You can make a branch for any little idea you want to mess with or any tricky feature you are working on. It's quite easy to then merge these branches, share them with friends, update them from other's repositories etc. This is a level of power and control that you can not get with svn.
- User Interface
Git was originally designed to function as a back-end suite that would support easy to use front-end utilities. That has changed over time, and it now includes a nice set of commands and tools that make it work just like you would expect. For sure Git doesn't have the GUI plugins like SVN or CVS and it will take some learning, but I think the benefits in the long term will far, far outweight the initial investment.
There is a Tk interface, GitK, which is incredibly useful to visually look at the history of a repository, merges, branches etc. There is also git-web, which lets you view the repository online. Git also lets you publish a repository just by copying a directory to an http accessible location. This means anyone can share their ideas, features, abstractions etc, without setting up a server, getting permission for a centralized location or anything. Also relevant to the user experience is speed. Git blows away all the other systems in terms of speed. It does everything faster, and you really notice this because it changes what you do. In some of the other systems, like Bazaar-ng, committing, pulling and pushing took so long I wouldn't do it that often, but with git it's all so cheap I do it every time I get a new unit test to pass.
- Technical
Git writes the repository into a highly compressed format, and then it does not mess with the files. Append only is the standard operation, except for when you occasionally compress the whole thing, in which case it can verify sanity. It is also much cleaner to work with in terms of permissions and access, just because of the whole usage model. I've had many experiences with subversion where the repository had to be recovered because of permissions issues and/or corruption. This is very bad, especially since it is a centralized server that everyone is counting on. It takes a root user to go in and run "svnadmin recover", which in my opinion is a command that shouldn't need to exist in something as important as a source repository.
Keith Packard who runs the X.org project wrote a very good post detailing his research and opinions into source control. It's a bit old now, but worth the read: http://keithp.com/blog/Repository_Formats_Matter/index.html
Sorry for the long post, but this is something I have dealt with a lot recently. In my mind distributed versioning is the only proper way to run a modern open source project. PD is a great piece of software with a seemingly cool and diverse group of developers, which seems perfect for a decentralized model. Either way, I think the decision should be made first between a centralized or distributed versioning system, and then the decision can be simplified to figuring out compatibility, usability etc. It's great news that Git now runs on windows though, because I think it is far better than the others. To quote one of Hans-Christoph's recent signature lines:
Mistrust authority - promote decentralization. - the hacker ethic
:-)
Ciao, Jeff
David Plans Casal wrote:
Speaking from experience, having suffered several migrations to prcs from cvs, to svn from cvs, and to darcs from svn, in commercial projects, I have to say the only one that worked well, made sense, and was least painful was cvs-->svn, and I'd vote for that.
David
On 23 Oct 2007, at 19:41, Stephen Sinclair wrote:
are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...
You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.
Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.
Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.
I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".
Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.
I won't try any more to push the idea, but I think it's worth considering.
Steve
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
The most technically amazing system in the world is useless if people in question don't want to spend the extra effort to learn how to use it.
It sounds to me like the best system is SVN as the core repository, then people can use git if they want, and sync it to SVN. Miller currently does this with Git->CVS.
I still don't think that git is all that hard to use once you understand the distributed paradigm, but in any case I think this would be a perfectly safe decision.
One thing I've learned more recently about version control is that it's not actually _all_ that hard to switch from one SCM to another, since there are usually conversion scripts in every direction imaginable. (Except, for som reason, Anything->CVS, heheh..), so I think it's worth trying out at least.
Just keep in mind that converting from subversion to something else in the future will be easiest if you stick to the standard /trunk/tag/branch structure. One of the features of svn that I just love is how there are no "modules", but instead every subfolder is like its own repository. However, this can also allow you to create structures that are difficult for other SCM systems to interpret when converting (since there is technically no difference between a branch and a tag), so sticking to /tags and /branches at the root level may be safest option.
Steve
Hallo, Stephen Sinclair hat gesagt: // Stephen Sinclair wrote:
The most technically amazing system in the world is useless if people in question don't want to spend the extra effort to learn how to use it.
It sounds to me like the best system is SVN as the core repository, then people can use git if they want, and sync it to SVN. Miller currently does this with Git->CVS.
I still don't think that git is all that hard to use once you understand the distributed paradigm, but in any case I think this would be a perfectly safe decision.
Actually I think, that the code in the CVS is not developed in a really distributed way anyway. Most of the stuff there is rather focused on single persons or very small teams. For example: Most commits in zexy come from IOhannes, most in list-abs from me, only Matju commits to DD, Hans has his pd-extended branch, but also uses a lot of separate patch files and the list goes on.
It's not like a team of 60 developers would work on the same files or even the same binary, like it is with the Linux kernel, it's much more separate. And I don't think it's separate, because of technical restrictions coming from CVS - it's separate because of the way the people in the Pd community work.
Ciao
Hallo, Stephen Sinclair hat gesagt: // Stephen Sinclair wrote:
Actually I think, that the code in the CVS is not developed in a really distributed way anyway. Most of the stuff there is rather focused on single persons or very small teams.
Hm, your second sentence seems to contradict your first sentence... ;-)
It only seems so. ;)
What I meant to express was, that somehow the repository is like a collection of many separate repositories. It's not so much distributed as divided into independent entities. At least a large part of it is.
Ciao
On Thu, 25 Oct 2007, Frank Barknecht wrote:
only Matju commits to DD
There are two people who commit, and it's only two because the fifteen other people who contributed didn't commit their contributions by themselves (not that I forbade them to or anything).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, Oct 24, 2007 at 09:27:15PM -0400, Hans-Christoph Steiner wrote:
It sounds to me like the best system is SVN as the core repository, then people can use git if they want, and sync it to SVN. Miller currently does this with Git->CVS.
So wait, Miller is currently using Git? It seems to me that that is a major pro in favour of other developers using Git. The big issue with Pd development (apart from some slightly sharp personalities sometimes) is with:
a) Miller not accepting people's patches, often without giving a reason. b) People finding it difficult to merge Miller's monolithic changes (e.g. what Tim had to do with the devel branches).
Surely if more people were also using git it would make both of those issues moot since Miller could more easily pull the patches he wanted and people could more easily merge Miller's changes.
On the other hand it might change nothing and everyone will continue to refuse to merge good patches and fork eachothers code bases. Maybe it has more to do with license issues, such as most developers releasing source under the GPL whilst Miller releases under the BSD? I would love to hear some comments from Miller about this, especially if he's publishing his Git repository somewhere.
Best,
Chris.
------------------- http://mccormick.cx
I think it doesn't matter whether I have to do a 'git pull' or a 'patch' to apply patches. The hard thing for me with patches is that I feel I should understand the patch fully and believe it both works and that it won't make future trouble. For the last month or more I've been working on HC's font patch, trying to adapt it so that it's bug-free but still accomplishes HC's aim.
Another thing is that, git or svn or whatever, I don't like to make code available to others until I believe it works. I'd feel uncomfortable putting every little 'commit' up for the whole Pd community to stumble over. Roght now, for instance, my own copy of Pd is out of order until I can find a path through the font mess.
I don't think the GPL/BSD thing applies much to patches; I always assume that patches that show up on sourceforge fall under Pd's license unless otherwise noted.
cheers Miller
On Wed, Oct 24, 2007 at 10:18:21PM -0400, Chris McCormick wrote:
On Wed, Oct 24, 2007 at 09:27:15PM -0400, Hans-Christoph Steiner wrote:
It sounds to me like the best system is SVN as the core repository, then people can use git if they want, and sync it to SVN. Miller currently does this with Git->CVS.
So wait, Miller is currently using Git? It seems to me that that is a major pro in favour of other developers using Git. The big issue with Pd development (apart from some slightly sharp personalities sometimes) is with:
a) Miller not accepting people's patches, often without giving a reason. b) People finding it difficult to merge Miller's monolithic changes (e.g. what Tim had to do with the devel branches).
Surely if more people were also using git it would make both of those issues moot since Miller could more easily pull the patches he wanted and people could more easily merge Miller's changes.
On the other hand it might change nothing and everyone will continue to refuse to merge good patches and fork eachothers code bases. Maybe it has more to do with license issues, such as most developers releasing source under the GPL whilst Miller releases under the BSD? I would love to hear some comments from Miller about this, especially if he's publishing his Git repository somewhere.
Best,
Chris.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
The hard thing for me with patches is that I feel I should understand the patch fully and believe it both works and that it won't make future trouble. For the last month or more I've been working on HC's font patch, trying to adapt it so that it's bug-free but still accomplishes HC's aim.
one way to go would be: 1. point hc to the bugs, ask him to fix them 2. when the patch is bug-free, ask hc to document it 3. read the docs, read the code, try to understand it 4. point hc to the issues that you don't like in the code 5. review the patch again 6. if the patch doesn't match your criteria, go to point 4
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Who need fossil fuel when the sun ain't goin' nowhere Amiri Baraka
On Oct 25, 2007, at 3:58 AM, Tim Blechmann wrote:
The hard thing for me with patches is that I feel I should understand the patch fully and believe it both works and that it won't make future trouble. For the last month or more I've been working on HC's font patch, trying to adapt it so that it's bug-free but still accomplishes HC's aim.
one way to go would be:
- point hc to the bugs, ask him to fix them
- when the patch is bug-free, ask hc to document it
- read the docs, read the code, try to understand it
- point hc to the issues that you don't like in the code
- review the patch again
- if the patch doesn't match your criteria, go to point 4
Yes, thankfully we do know how to talk to each other ;-P
.hc
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Who need fossil fuel when the sun ain't goin' nowhere Amiri Baraka _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
On Wed, 24 Oct 2007, Chris McCormick wrote:
On the other hand it might change nothing and everyone will continue to refuse to merge good patches and fork eachothers code bases.
When the policy is to refuse any patch that don't add or fix any functionality, and to refuse any part of a patch that doesn't add or fix any functionality, and to aim for the smallest patches possible, the whole project necessarily decreases in some form of quality that users are oblivious to, but that determines the level of difficulty of any further improvement.
Switching to svn or git doesn't fix policy problems.
Maybe it has more to do with license issues, such as most developers releasing source under the GPL whilst Miller releases under the BSD?
No. Patches to Pd itself are all assumed to be SIBSD'd unless explicitly stated otherwise, and I have never seen someone requesting to add GPL'd code directly into Pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
A distributed repository sounds interesting, but given Linus Torvald's love of KDE, constant dissing of usability, and the fact that git has 119 commands, this gives me pause.
Sounds like software designed for someone with an encyclopedic memory. I really only use 8 commands in CVS (update, commit, checkout, add, remove, tag, diff, import).
.hc
On Oct 23, 2007, at 10:25 AM, Stephen Sinclair wrote:
I don't want to sound like I'm just trumpeting the latest hype, but someone is going to say it, so it may as well be me:
Considering the highly distributed nature of Pd development (lots of people with dev access working on different, independent parts), I really think a distributed system like Git would be appropriate to the Pd project.
Instead of committing your changes to one big repo, you just work on your own, developing features, and you tell people when you've done something cool, and they are free to copy it from you and merge it into their version (or not). It takes the politics right out of things. Everyone is in charge of their own work, and no one else's.
I've been playing with it a lot lately and it's really got some advantages in how it deals with team work. There are also lots of scripts to help making a transition from CVS.
In any case it's not my decision, but I highly recommend checking it out. It works on Windows under MingW as well as OS X and Linux.
http://git.or.cz/ http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
Steve
On 10/22/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey,
There was gung-ho talk back at PdCon about switching to SVN. It's been quiet recently, any word on that? :)
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Tue, 2007-10-23 at 11:56 -0400, Hans-Christoph Steiner wrote:
A distributed repository sounds interesting, but given Linus Torvald's love of KDE, constant dissing of usability, and the fact that git has 119 commands, this gives me pause.
in order to evaluate git, one should maybe give it a try ...
Sounds like software designed for someone with an encyclopedic memory. I really only use 8 commands in CVS (update, commit, checkout, add, remove, tag, diff, import).
do you remember all the cvs command options?
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett
On Oct 23, 2007, at 12:51 PM, Tim Blechmann wrote:
On Tue, 2007-10-23 at 11:56 -0400, Hans-Christoph Steiner wrote:
A distributed repository sounds interesting, but given Linus Torvald's love of KDE, constant dissing of usability, and the fact that git has 119 commands, this gives me pause.
in order to evaluate git, one should maybe give it a try ...
Sounds like software designed for someone with an encyclopedic memory. I really only use 8 commands in CVS (update, commit, checkout, add, remove, tag, diff, import).
do you remember all the cvs command options?
There are very many SCM systems out there, there are even many distributed SCM systems out there. My experience is that Linus is super focused on issues that affect him and pretty much totally ignores other issues that don't affect him. Also, he approaches things with arrogance. So chances are, that effects the software he writes. I am sure git works well for Linux, but Pd is a very different community. My guess is that git is a good tool for people who are immersed in C all day, everyday. That describes none of the Pd developers.
First, I think we need to narrow the options, then evaluate. I want to write code, not play with SCM systems. That said, I do think that a distributed system sounds very appealing, what I don't quite understand is how the "main" repository works. Tom Schouten made darcs sound quite appealing, I am sure Claude likes it, since it's written in Haskell ;)
.hc
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett
------------------------------------------------------------------------ ----
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
My experience is that Linus is super focused on issues that affect him and pretty much totally ignores other issues that don't affect him. Also, he approaches things with arrogance. So chances are, that effects the software he writes.
i am not sure whether one should judge the functionality of a piece of software by the personality of the author ...
I want to write code, not play with SCM systems.
i think it took me two days to merge devel_0_38 to devel_0_39 with cvs ... it could have been done in one day with git ... 4 hours learning git and setting up the repository, 2 hours doing the merge :)
cheers, tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett