From: Maarten B. <sou...@ds...> - 2006-04-11 20:04:13
|
In response to Scott's reply on the user list (see below): I think subversion is a lot better than cvs, but I doubt the outage is in the equation. This can probably happen to subversion just as well. Also the SF team promised the 4 hour delay would disappear for cvs in the near future. I'm glad someone already experienced just volunteered to help with the transition if we agree to have one ;-) But before that I would like to see some discussion on it. My gutt feeling says we should do it but I prefer to see some good arguements. And then there is priority. I think releasing a new version of SDCC should have a higher priority than changing our source code control system right now. And for that I would like to postpone any transition until after the release. All comments are welcome, Maarten > Maarten Brock wrote: > > As Raphael already mentioned Anonymous CVS is offline on sourceforge. But > > most snapshots are still generated, so you can use one of these instead. > > The continuous lack of CVS reliability and the 4 hour delay to the > anonymous repository have been ongoing nagging problems in my opinion. > This recent CVS outage finally encouraged me to move gpsim to SVN. Maybe > we should do the same for SDCC? > > Scott |
From: Bernhard H. <ber...@be...> - 2006-04-13 19:12:26
|
> Subversion benefits: > > * handles renaming of files and directories > not ideal yet, expected to be better in 1.4, but already > much better than CVS which can't deal with it at all This is good news, just in time. The implementation of the VPATH feature is finished and ready to commit. There are 54 "Makefile" files, which have to be renamed in "Makefile.in". In cvs I would have to remove the old files and then add the renamed files again. The big drawback of this procedure in cvs is that all the history of these files gets lost. Just for this commit I clearly prefer to do it with subversion. > I think postponing a transition over to SVN until after the next > release is a good idea (assuming the next release is imminent). Well, under normal conditions I would agree. But at the moment I'm counting on my harddisk beside the 54 Makefiles, which need renaming, another 103 diffs. I really would like to swap my work out to the repository, the sooner the better. Therefore I vote for a quick conversion to SVN. Bernhard |
From: Borut R. <bor...@si...> - 2006-04-13 19:53:11
|
Berhard, I was just about to ask you how you are proceeding with VPATH feature. I'm glad that you finished it! About SVN: the transition of gpsim was done smoothly and without any problem, so I vote to migrate sdcc too. I also thought that is better to do it after the release, but after reading your mail I agree that it would be better if we do it before, unless we postpone the VPATH too. On the other hand, I received the mail from sourceforge saying: ... Your project has a 100000 k soft quota and your project is currently using 246760 k of disk. ... which I hope will be at least partially solved with VPATH, so we have to integrate VPATH ASAP. In short: I agree to make the migration to SVN before the release. Borut Bernhard Held wrote: >>Subversion benefits: >> >>* handles renaming of files and directories >> not ideal yet, expected to be better in 1.4, but already >> much better than CVS which can't deal with it at all >> >> >This is good news, just in time. The implementation of the VPATH feature is >finished and ready to commit. There are 54 "Makefile" files, which have to be >renamed in "Makefile.in". In cvs I would have to remove the old files and >then add the renamed files again. The big drawback of this procedure in cvs >is that all the history of these files gets lost. > >Just for this commit I clearly prefer to do it with subversion. > > > >>I think postponing a transition over to SVN until after the next >>release is a good idea (assuming the next release is imminent). >> >> >Well, under normal conditions I would agree. But at the moment I'm counting >on my harddisk beside the 54 Makefiles, which need renaming, another 103 >diffs. I really would like to swap my work out to the repository, the sooner >the better. Therefore I vote for a quick conversion to SVN. > >Bernhard > > |
From: Bernhard H. <sdc...@be...> - 2006-04-13 20:22:25
|
> Berhard, I was just about to ask you how you are proceeding with VPATH > feature. I'm glad that you finished it! Me too ;-))) > Your project has a 100000 k soft quota and your project is currently using > 246760 k of disk. ... > which I hope will be at least partially solved with VPATH, so we have to > integrate VPATH ASAP. Hmm, I'm afraid VPATH can not significantly save space. The sdcc source needs 30 MByte, while the build tree with the output of the regression tests consumes 742 MByte. The advantage of using VPATH is less than 5%! Another problem is: If you decide to use only one source tree on the CF, then the build on all other hosts will depend on the succesfull checkout of the source by a "master" host. If this "master" fails (unfortunately they fail quite often) all other builds will fail too. I just want to show that using one source tree makes the build even more complex and maybe fragile. Finally it's your decision! Bernhard |
From: Maarten B. <sou...@ds...> - 2006-04-13 20:53:52
|
Borut, Bernhard and others, I agree. This is a very good argument. Renaming or moving files is impossible with cvs but possible with svn. I guess the VPATH option is very welcome before doing a new release. Please setup a transition plan so we all know what to expect. If possible with dates. Something like: 1) disable cvs commits 2) make transition to svn 3) enable svn 4) commit VPATH ;-) Meanwhile a list of bugs we want to see fixed before a release could be created. Maybe some features should be on the list too. Based on this list we can try to lay out a release plan. I think the wiki can be used for this. Who will be in charge of the transition and the release? PS: Congrats on the VPATH implementation > Berhard, I was just about to ask you how you are proceeding with VPATH > feature. I'm glad that you finished it! > > About SVN: the transition of gpsim was done smoothly and without any > problem, so I vote to migrate sdcc too. I also thought that is better to > do it after the release, but after reading your mail I agree that it > would be better if we do it before, unless we postpone the VPATH too. > > On the other hand, I received the mail from sourceforge saying: > ... > > Your project has a 100000 k soft quota and your project is currently using 246760 k of disk. > ... > which I hope will be at least partially solved with VPATH, so we have to integrate VPATH ASAP. > > In short: I agree to make the migration to SVN before the release. > > Borut > > > Bernhard Held wrote: > > >>Subversion benefits: > >> > >>* handles renaming of files and directories > >> not ideal yet, expected to be better in 1.4, but already > >> much better than CVS which can't deal with it at all > >> > >> > >This is good news, just in time. The implementation of the VPATH feature is > >finished and ready to commit. There are 54 "Makefile" files, which have to be > >renamed in "Makefile.in". In cvs I would have to remove the old files and > >then add the renamed files again. The big drawback of this procedure in cvs > >is that all the history of these files gets lost. > > > >Just for this commit I clearly prefer to do it with subversion. > > > > > > > >>I think postponing a transition over to SVN until after the next > >>release is a good idea (assuming the next release is imminent). > >> > >> > >Well, under normal conditions I would agree. But at the moment I'm counting > >on my harddisk beside the 54 Makefiles, which need renaming, another 103 > >diffs. I really would like to swap my work out to the repository, the sooner > >the better. Therefore I vote for a quick conversion to SVN. > > > >Bernhard > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Borut R. <bor...@si...> - 2006-04-14 05:28:22
|
Maarten Brock wrote: >Borut, Bernhard and others, > >I agree. This is a very good argument. Renaming or moving files is >impossible with cvs but possible with svn. I guess the VPATH option is >very welcome before doing a new release. > >Please setup a transition plan so we all know what to expect. If >possible with dates. Something like: >1) disable cvs commits >2) make transition to svn >3) enable svn >4) commit VPATH ;-) > > I think that we have to do the transition ASAP, but still leave some time if anybody has objections. I propose to do the transition in the second half of the next week: 1) disable cvs commits: 2006-04-18 2) make transition to svn: 2006-04-18 3) enable svn: whatever it takes to do the transition. My estimate is ~2dys: 2006-04-20 4) update nightly builds to use svn instead cvs: Borut 4) commit VPATH ;-): Bernhard 5) redesign nightly builds with VPATH I can do the transition. >Meanwhile a list of bugs we want to see fixed before a release could >be created. Maybe some features should be on the list too. Based on >this list we can try to lay out a release plan. I think the wiki can be used >for this. > > Agree. I already created an empty SDCC 2.6.0 Release page. >Who will be in charge of the transition and the release? > >PS: Congrats on the VPATH implementation > > Borut |
From: Scott D. <sc...@da...> - 2006-04-11 20:58:18
|
Maarten Brock wrote: > In response to Scott's reply on the user list (see below): > > I think subversion is a lot better than cvs, but I doubt the outage is in > the equation. This can probably happen to subversion just as well. Also > the SF team promised the 4 hour delay would disappear for cvs in the > near future. The Subversion servers are currently configured such that it takes more than a single point failure in the system to cause a system failure. The CVS servers are susceptible to single-point failures. However, apparently SF is addressing this issue. > I'm glad someone already experienced just volunteered to help with > the transition if we agree to have one ;-) You mean do I have the guts to click on the CVS->SVN radio button in the admin page? :) It took me a week of discussing with others on whether or not gpsim should switch over. It took minutes to actually make the transition! > But before that I would like to see some discussion on it. My gutt > feeling says we should do it but I prefer to see some good arguements. > > And then there is priority. I think releasing a new version of SDCC > should have a higher priority than changing our source code control > system right now. And for that I would like to postpone any transition > until after the release. I think postponing a transition over to SVN until after the next release is a good idea (assuming the next release is imminent). Here's the thread on the gpsim mailing discussing the transition: http://sourceforge.net/mailarchive/forum.php?thread_id=10087997&forum_id=10321 In addition here's a response Eric Smith sent to me privately: ------------------------- >Is there anything specific thing makes Subversion better than CVS in > your opinion? I typically look at it the other way. If I was using Subversion, what might make me what to switch to CVS? And the answer is "nothing". Subversion benefits: * handles renaming of files and directories not ideal yet, expected to be better in 1.4, but already much better than CVS which can't deal with it at all * atomic commits * faster creation of tags and branches, O(1) instead of O(n) * branches and tags are identical instead of being separate concepts * doesn't use the confusing CVS file revision numbers * each commit has a unique version number, so you can use that version number on a checkout or update to get the state of the entire tree at that point, rather than having to figure out what date & time to use * metadata versioning useful for tracking merges, though that is expected to be done automatically in a future version of Subversion * better hooks for script integration on server * Subversion library has well-defined APIs for use from programs and scripts * better client/server architecture supports multiple access protocols Subversion Drawbacks: * doesn't have a sequential revision number for individual files. In other words, with CVS, the revs of a file are 1.1, 1.2, 1.3, 1.4, etc., while is SVN, they might be 37, 62, 118, and 123. At first this seemed a bit annoying, but over time I've decided that the Subversion approach is actually better * doesn't use "changesets" as a first-class data type like Bitkeeper, Git, and other distributed version control systems. But then, neither did CVS. There's an SVK wrapper if you want that model, though. Eric ---------------------- SVN maintains a local copy of the repository. This makes it much faster than CVS for doing things like diffs. However, this repository can be quite large. For gpsim it's about 45M. Scott |
From: Jim P. <ji...@jt...> - 2006-04-11 21:47:44
|
> The Subversion servers are currently configured such that it takes more > than a single point failure in the system to cause a system failure. With SVN::Mirror, it is also very easy to create a read-only mirror of a subversion repository, with full history. I can host such a mirror if anything thinks it would be beneficial. > * each commit has a unique version number, so you can use that version > number on a checkout or update to get the state of the entire > tree at that point, rather than having to figure out what > date & time to use Instead of referring to interim SDCC builds using the changelog revision number, we can use this global revision number, which is both easier and more precise. Plus, a reference to "SDCC r1234" is clear in the context of a Subversion repository, whereas it took me forever to figure out what "SDCC #1234" meant for something hosted in CVS. :) > SVN maintains a local copy of the repository. This makes it much faster > than CVS for doing things like diffs. However, this repository can be > quite large. For gpsim it's about 45M. It's a local copy of the base revision, not the entire repository. In general, the working copy will be about twice as large as an equivalent CVS checkout. It may be more due to filesystem inefficiency, as svn keeps lots of small files around. I've heard this is a particularly bad problem for gcc, but that's an extreme example. For my local copy of sdcc that I keep in svn (several months old): $ du --apparent-size -sh sdcc-exported/ sdcc-workingcopy/ 17M sdcc-exported/ 35M sdcc-workingcopy/ $ du -sh sdcc-exported/ sdcc-workingcopy/ 21M sdcc-exported/ 66M sdcc-workingcopy/ So in this case, the working copy is storing twice as much data but takes up three times as much space on disk. Personally, I think the benefits far outweigh the extra space. (On the other hand, if you're using svk, then yes, you do keep a local copy of the full repository). -jim |