SourceForge just announced that their Subversion service is out of beta. Is it time to give it a try? It sounds really great, a lot more that I expected.
It seems that now would be a good time to start testing since development activity is pretty low. (perhaps everyone is busy with other things...). I have not used svn really at all, so I am probably not the one to spearhead this effort. But I can test while learning SVN.
.hc
Begin forwarded message:
Subversion General Availability
The SourceForge.net team is pleased to announce the General Availability of Subversion service to SourceForge.net-hosted projects, effective 2006-02-21. This service offering is in addition to our existing CVS service; as with all of our services, projects may select (and enable in the project admin pages) the portion of our offering that best meets their needs.
We wish to extend our thanks to the many projects and developers who have helped us to test our Subversion service as part of our six-week beta, which completed last week. Our particular thanks go to these projects, whose members provided substantial feedback regarding the new service:
- Inkscape - http://sourceforge.net/projects/inkscape/
- DejaVu Fonts - http://sourceforge.net/projects/dejavu/
- ScummVM - http://sourceforge.net/projects/scummvm/
- evilnet - http://sourceforge.net/projects/evilnet/
Our Subversion service includes:
SSL-based Repository Access:
- Developer Subversion access via HTTPS, auth is requested when you
perform a write operation
- Anonymous Subversion access via HTTPS
- No sync delays between developer and anonymous Subversion access
- Per-developer access control over repository access (ACL support
to be added in the future) via the SourceForge.net permissions system
Web-based viewing:
- Web-based repository access via ViewVC (formerly known as ViewCVS)
On-demand self-service backups and mirroring capability:
- Read-only rsync access to the repository to permit backups and
remote mirroring
Ease of migration:
- Automated self-service migration of your SourceForge.net project CVS
repository, CVS tarball, or Subversion dump to our Subversion service
Well-considered add-ons to basic service:
- A selected set of hook scripts, including commit email support and
CIA bot support
- Statistics tracking of Subversion repository activity
Service may be enabled by project administrators in the "Subversion" section of the Project Admin pages.
Complete service documentation is available at: http://sf.net/docs/E09/
Documentation is provided for supported clients at: http://sf.net/docs/F06/ for the command-line SVN client http://sf.net/docs/F07/ for TortoiseSVN
Our support of Subversion has been based on substantial research and testing in the past few months, which we have pursued specifically based on requests from the community. SourceForge.net continues to consider new technologies and evaluate community requests in further strengthening our service offering.
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
On 25 Feb 2006, at 01:51, Hans-Christoph Steiner wrote:
SourceForge just announced that their Subversion service is out of beta. Is it time to give it a try? It sounds really great, a lot more that I expected.
Yes please! I've been using SVN for 3 years now (as a user, not admin), and in comparison, working with CVS is such a drag.
It seems that now would be a good time to start testing since development activity is pretty low. (perhaps everyone is busy with other things...). I have not used svn really at all, so I am probably not the one to spearhead this effort. But I can test while learning SVN.
I wouldn't feel comfortable setting up the initial repos, but I can do if no-one else (more experienced) is up for it.
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
Hallo!
I wouldn't feel comfortable setting up the initial repos, but I can do if no-one else (more experienced) is up for it.
maybe this is a chance to reorganize the structure of the externals+etc. a little bit? (but I guess it's too early to make organize it by functionality and not by authors ...)
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Hallo!
I wouldn't feel comfortable setting up the initial repos, but I can do if no-one else (more experienced) is up for it.
maybe this is a chance to reorganize the structure of the externals+etc. a little bit?
I agree, that there should be a little cleanup going on, even as cleaning up in SVN is much easier than in CVS.
For example I would vote for dropping "abstractions" and merging it with "externals" to become a single "extensions" tree.
Ciao
On Feb 25, 2006, at 7:00 PM, Frank Barknecht wrote:
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Hallo!
I wouldn't feel comfortable setting up the initial repos, but I can do if no-one else (more experienced) is up for it.
maybe this is a chance to reorganize the structure of the externals +etc. a little bit?
I agree, that there should be a little cleanup going on, even as cleaning up in SVN is much easier than in CVS.
For example I would vote for dropping "abstractions" and merging it with "externals" to become a single "extensions" tree.
I think that cleaning up is a good idea, but I think the conversion is going to be complicated enough as it is. So I propose that we convert, then cleanup.
"abtractions", "extensions", and "externals" are pretty much redundant, so one "extensions" directory would make sense, making it :
doc extensions pd scripts
But I have to say, yes the CVS is messy, but it works more or less. And it would take a lot of work to clean it up. I'd rather have svn's easier branching and merging before a cleaned up repository. But if anyone wants to take on the cleanup project, I say go for it.
.hc
________________________________________________________________________ ____
"[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
On Tue, 28 Feb 2006, Hans-Christoph Steiner wrote:
I think that cleaning up is a good idea, but I think the conversion is going to be complicated enough as it is. So I propose that we convert, then cleanup.
When would this happen? Shouldn't we have a developers meeting on IRC before it happens? When would that meeting be?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 28, 2006, at 7:56 AM, Mathieu Bouchard wrote:
On Tue, 28 Feb 2006, Hans-Christoph Steiner wrote:
I think that cleaning up is a good idea, but I think the conversion is going to be complicated enough as it is. So I propose that we convert, then cleanup.
When would this happen? Shouldn't we have a developers meeting on IRC before it happens? When would that meeting be?
Yes a meeting would be good. So far there seem to be no volunteers to set it up, so it doesn't look like its going to happen soon...
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
It seems that now would be a good time to start testing since development activity is pretty low. (perhaps everyone is busy with other things...). I have not used svn really at all, so I am probably not the one to spearhead this effort. But I can test while learning SVN.
I wouldn't feel comfortable setting up the initial repos, but I can do if no-one else (more experienced) is up for it.
imo, subversion is both easier to use and more powerful than cvs ... but converting the current cvs repository to svn is not really trivial ... because of different branch handling ...
some people have branches in their external folders, which would probably be converted to subfolders ... making the directory structure a bit messy ... imo, it would be better to set up multiple repositories for the externals, abstractions, and the pd core ... maybe ever multiple repositories for the externals ...
but maybe someone has a better idea?
tim
On 25 Feb 2006, at 12:38, Tim Blechmann wrote:
imo, subversion is both easier to use and more powerful than cvs ... but converting the current cvs repository to svn is not really trivial ... because of different branch handling ...
I've seen two or three cvs-->svn conversions, and sure, they're not usually a 1-step process, or trivial.
imo, it would be better to set up multiple repositories for the externals, abstractions, and the pd core ... maybe ever multiple repositories for the externals ...
Multiple repos for externals, abs and pd core makes sense, but not for each externals or branch of externals, IMO. I think externals should be a repo on its own.
However, I do agree that there should be some clean up of our externals world before an SVN repo structure for it is made. I know I'm guilty with our own directory in there.
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
Hi all,
imo, it would be better to set up multiple repositories for the externals, abstractions, and the pd core ... maybe ever multiple repositories for the externals ...
Multiple repos for externals, abs and pd core makes sense, but not for each externals or branch of externals, IMO. I think externals should be a repo on its own.
i don't think there is a real reason for multiple repositories. I have been working with split repositories for quite a while because of missing path-wise access control in older svn versions, but this restriction is gone now. I find it inconvenient and unnecessary. SVN has far better capabilities of dealing with directories like cvs, so this would only complicate things. If SF provides the repo there will probably be only a single one available anyway.
best greetings, Thomas
On Feb 25, 2006, at 8:39 AM, Thomas Grill wrote:
Hi all,
imo, it would be better to set up multiple repositories for the externals, abstractions, and the pd core ... maybe ever multiple repositories for the externals ...
Multiple repos for externals, abs and pd core makes sense, but not for each externals or branch of externals, IMO. I think externals should be a repo on its own.
i don't think there is a real reason for multiple repositories. I have been working with split repositories for quite a while because of missing path-wise access control in older svn versions, but this restriction is gone now. I find it inconvenient and unnecessary. SVN has far better capabilities of dealing with directories like cvs, so this would only complicate things. If SF provides the repo there will probably be only a single one available anyway.
First off, it would be great if you SVN users could explain the differences from CVS and how it will affect us. For example, I don't get the branch=folders stuff, that doesn't exist in CVS.
Everything that goes into Pd-extended should be in one repository. Not only does it make tagging easier, but also it makes release branches possible. For future Pd-extended releases, I plan on making a branch. With such a complicated program, its necessarily to be able to commit fixes that are specific to a release separately from HEAD. Then those fixes can be merged in or not depending on the fix. This can't be done with tagging.
All of the Pd-extended code doesn't have to be maintained in the Pd repository, but instead stable versions can be imported. This would work well with Gem, PDP, GridFlow, and Thomas' flext, etc. I think this would be a much better setup for externals/grill rather than the current automatic mirror.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
First off, it would be great if you SVN users could explain the differences from CVS and how it will affect us. For example, I don't get the branch=folders stuff, that doesn't exist in CVS.
I think it's important that everyone reads the relevant chapters in the SVN book on branching, tagging, and repository layout: http://svnbook.red-bean.com/ (Chapters 2 and 4, of course the others are good to read as well.)
Basically the main conceptual difference between CVS and SVN in this area is, that branches and tags are simply copies. Want to make a tag? Use: "svn copy mystuff somewhere_else". Need a branch instead? Use: "svn copy somewhere_else". Oh, and the tag called "HEAD" in CVS is usually a directory called "trunk" in SVN.
In both cases "somewhere_else" will just be copies of "mystuff", a kind of snapshot. Tags then are snapshots, which you will never touch again, while branches are snapshots to work on further.
For the repository layout this means, that we should have everything, that could become a tag or branch of its own, in its own directory, so that copying becomes easy. Our externals for example might like to find Pd's headers in "../../../pd/src". Now with a layout like:
trunk/externals trunk/pd tags/... branches/...
creating a complete tag would be done like:
$ svn copy trunk tags/pd-all/pd-all-0.39
And you could create a workign branch for pd-extended easily:
$ svn copy trunk branches/pd-extended/pd-extended-0.39
Creating just a pd-release-tag also is possible:
$ svn copy trunk/pd tags/pd/pd-0.41-test2
however doing the same for externals:
$ svn copy trunk/externals tags/externals/pd-externals-for-0.41
will add a new directory level so that headers in "../../../pd/src" won't be found anymore. This has to be taken into account.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Oh, and the tag called "HEAD" in CVS is usually a directory called "trunk" in SVN.
Let me rephrase this a bit, because it's not correct the way I said it: When considering HEAD as a revision, then of course svn also has a current, HEAD revision. What I actually meant to say was that the MAIN branch of CVS usually is a "trunk" directory (or many of them) in SVN.
Ciao
On 26 Feb 2006, at 09:51, Frank Barknecht wrote:
Oh, and the tag called "HEAD" in CVS is usually a directory called "trunk" in SVN.
Let me rephrase this a bit, because it's not correct the way I said it: When considering HEAD as a revision, then of course svn also has a current, HEAD revision. What I actually meant to say was that the MAIN branch of CVS usually is a "trunk" directory (or many of them) in SVN.
It's probably worth noting that there is a very good 'SVN for CVS users' chapter in the red bean book, here:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.forcvs
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Feb 26, 2006, at 6:29 AM, David Plans Casal wrote:
On 26 Feb 2006, at 09:51, Frank Barknecht wrote:
Oh, and the tag called "HEAD" in CVS is usually a directory called "trunk" in SVN.
Let me rephrase this a bit, because it's not correct the way I said it: When considering HEAD as a revision, then of course svn also has a current, HEAD revision. What I actually meant to say was that the MAIN branch of CVS usually is a "trunk" directory (or many of them) in SVN.
It's probably worth noting that there is a very good 'SVN for CVS users' chapter in the red bean book, here:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.forcvs
Thanks, that's a good start.
But I must say, there is an arrogance to the documentation which I find distasteful. I'd like to see the "advantages and disadvantages" section, rather than "forget all you know, because SVN is so much better". That's a dangerous attitude, every system has disadvantages, and the developers should be aware of them.
For example, I am sure there are disadvantages to having per-commit versions rather than per-file like CVS. I'd like to hear the discussion rather than having someone tell me "forget the other way, this way is better". Here's a good paper comparing CVS and SVN:
http://www.jini.org/docs/cvs_vs_subversion.pdf
Here's something from the GNU Arch wiki:
http://wiki.gnuarch.org/SubVersionAndCvsComparison
Here's a discussion from the gcc dev list about their switch:
http://gcc.gnu.org/ml/gcc/2005-10/msg00528.html
I think they spell it out, basically branching and merging is better in SVN, the rest is largely the same in terms of efficiency. I think we should be doing more branching and merging, so its sounds like SVN is the way. I just want to make sure what we are getting into.
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
But I must say, there is an arrogance to the documentation which I find distasteful. I'd like to see the "advantages and disadvantages" section, rather than "forget all you know, because SVN is so much better".
SVN: a less crufty CVS which fixes a few problems, namely renaming/moving/deleting files. it's not a new paradigm, and tools like SVK have spring up to attempt to make the SVN storage backend behave more like darcs/bazaar/etc..
Darcs/Bazaar-NG: offer many time/painsavers applicable to the nature of PD development like multiple branches, developers with their own repositories, and are written by people who understand how open source projects are written, whereas CVS is a relic of the days of a small academic department...
my experience with these RCS's is akin to graduating from compiling something on redhat or debian where you need to grab hordes of '-dev' packages, and are stuck with the same compiler the rest of your system is built with, vs doing the same on gentoo where you have a suite of tools to handle intra-lib reverse-dependenency linkages, easily switching between compiler/lib versions etc..they were built from the ground up to fix problems more interesting than simply renaming dirs..
Sourceforge: is pretty useless, except for its rather basic patch tracker. the public CVS access is inaccessible about 20% of the time for the past few years, and their website has 7 rows toolbars and 2 rows of ad banners, and none of them have useful stuff in them
Launchpad: a 'sourceforge 2.0' provided by the folks at Canonical (also known for Ubuntu). already has 131 projects using it, and its website is significantly more useful, with an easy overview of the most active current branches on the front page, not to mention a better bugtracker, and nice Bazaar integration.
additionally a user does not have to beg the admins for acess "Decentralized Revision Control Systems Give users the ability to work in a bazaar fashion over the internet. Users of decentralized Bazaar-NG can get right to comitting on their favorite free software projects without requiring special permission from projects that use Bazaar-NG"
my vote? Launchpad :)
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Basically the main conceptual difference between CVS and SVN in this area is, that branches and tags are simply copies. Want to make a tag? Use: "svn copy mystuff somewhere_else". Need a branch instead? Use: "svn copy somewhere_else".
Of course here I meant "svn copy mystuff somewhere_else" as well... Never believe a guy from Cologne anything during carneval...
Ciao
Hi Hans-Christoph,
All of the Pd-extended code doesn't have to be maintained in the Pd repository, but instead stable versions can be imported. This would work well with Gem, PDP, GridFlow, and Thomas' flext, etc. I think this would be a much better setup for externals/grill rather than the current automatic mirror.
could you rephrase that please. I don't seem to understand what you mean exactly with "importing stable versions", or avoiding the "current automatic mirror"
thanks, Thomas
On Feb 27, 2006, at 7:11 AM, Thomas Grill wrote:
Hi Hans-Christoph,
All of the Pd-extended code doesn't have to be maintained in the Pd repository, but instead stable versions can be imported. This would work well with Gem, PDP, GridFlow, and Thomas' flext, etc. I think this would be a much better setup for externals/grill rather than the current automatic mirror.
could you rephrase that please. I don't seem to understand what you mean exactly with "importing stable versions", or avoiding the "current automatic mirror"
As far as I understand it, externals/grill is hosted in your repository, and then every night, it is mirrored to pure-data CVS. I am saying instead of this setup, it would make more sense to import the code from your repository only when you make a release. No one currently uses branches against externals/grill to track changes to that area, so I see now benefit to having it mirrored in pure-data CVS.
Instead, if stable releases were in external/grill, then we would not have to worry about various inevitable development hiccups when building Pd-extended. I think this would also work well with Gem, PDP, and GridFlow, which are also managed in other repositories.
.hc
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Hi Hans-Christoph, i see. In fact, i turned off the automatic mirroring several months ago, so that the SF cvs is updated only when the respective project is under a buildable condition. Mirroring releasing only doesn't seem too good to me, since i don't release very often due to the work that is connected to preparing the packages. Fixes made in the meantime wouldn't be available for users in this case.
greetings, Thomas
As far as I understand it, externals/grill is hosted in your repository, and then every night, it is mirrored to pure-data CVS. I am saying instead of this setup, it would make more sense to import the code from your repository only when you make a release. No one currently uses branches against externals/grill to track changes to that area, so I see now benefit to having it mirrored in pure-data CVS.
Instead, if stable releases were in external/grill, then we would not have to worry about various inevitable development hiccups when building Pd-extended. I think this would also work well with Gem, PDP, and GridFlow, which are also managed in other repositories.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Feb 27, 2006, at 1:53 PM, Thomas Grill wrote:
Hi Hans-Christoph, i see. In fact, i turned off the automatic mirroring several months ago, so that the SF cvs is updated only when the respective project is under a buildable condition.
Whatever you want to call it, this is exactly what I am talking about. I didn't realize that you had stopped the mirroring. I'd just add that each time you send the files to the pure-data CVS, you increment the version in some fashion. Then it would be a release.
Mirroring releasing only doesn't seem too good to me, since i don't release very often due to the work that is connected to preparing the packages. Fixes made in the meantime wouldn't be available for users in this case.
I don't mean that everyone should mirror the release schedule of Pd- extended. I mean that they should import only stable releases once they are ready. Then Pd-extended will be build with whatever is there. That seems to be the most manageable solution for now.
.hc
greetings, Thomas
As far as I understand it, externals/grill is hosted in your repository, and then every night, it is mirrored to pure-data CVS. I am saying instead of this setup, it would make more sense to import the code from your repository only when you make a release. No one currently uses branches against externals/grill to track changes to that area, so I see now benefit to having it mirrored in pure-data CVS.
Instead, if stable releases were in external/grill, then we would not have to worry about various inevitable development hiccups when building Pd-extended. I think this would also work well with Gem, PDP, and GridFlow, which are also managed in other repositories.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
-- Thomas Grill http://grrrr.org
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
Multiple repos for externals, abs and pd core makes sense, but not for each externals or branch of externals, IMO. I think externals should be a repo on its own.
maybe one could do something in between ... e.g. the HEAD of externals will reside in trunk, while branches reside in branches/external/branchname ...
just an idea ...
Am 25.02.2006 um 14:46 schrieb Tim Blechmann:
Multiple repos for externals, abs and pd core makes sense, but not for each externals or branch of externals, IMO. I think externals should be a repo on its own.
maybe one could do something in between ... e.g. the HEAD of externals will reside in trunk, while branches reside in branches/external/branchname ...
This brings me to a strong argument for a single repository. PD core and externals can be much easier tagged for e.g. a Pd-extended-release. The organisation of tags and branches of course is another topic. If there's a trunk/external folder, than branches/external/branchname would be the natural choice.
greetings, Thomas
but converting the current cvs repository to svn is not really trivial ... because of different branch handling ...
some people have branches in their external folders, which would probably be converted to subfolders ... making the directory structure a bit messy ...
i've made good experiences with cvs2svn. Certainly branches would be converted to subfolders because this is the nature of svn. One could try what cvs2svn on the current cvs, then restructure the repo (which should be no great deal with svn), then release it for the community.
greetings Thomas
-
cdr -
David Plans Casal -
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann