From: Ian S. <ian...@st...> - 2008-08-15 08:16:41
|
OK This is the formal proposal to move the repository from CVS to subversion. There have been several votes in support already. If anyone objects please email the list before the end of August. I can do the conversion, and Amitha has volunteered to handle the subversion server issues. I also need someone to volunteer to fix up all the files in the repository that specifically refer to CVS. The main issues that comes to mind are the dashboard configuration, web page and documentation, but a proper search and evaluation of all references to "cvs" or "CVS" is essential. |
From: Wheeler, F. W (G. Research) <wh...@cr...> - 2008-08-15 11:18:36
|
Ian wrote: > I also need someone to volunteer to fix up all the files in > the repository that specifically refer to CVS. The main > issues that comes to mind are the dashboard configuration, > web page and documentation, but a proper search and > evaluation of all references to "cvs" or "CVS" is essential. I can do this. Fred |
From: Brad K. <bra...@ki...> - 2008-08-15 13:28:50
|
Ian Scott wrote: > OK This is the formal proposal to move the repository from CVS to > subversion. > > There have been several votes in support already. If anyone objects > please email the list before the end of August. > > I can do the conversion, and Amitha has volunteered to handle the > subversion server issues. I agree with this move. However, we should be careful designing the layout of the repository since this is our one chance to re-organize things. A typical layout is something like this: trunk/vxl branches/vxl-x.y tags/vxl-x.y.z where "x.y.z" are version numbers of course. Should we re-name the old release branches and tags into this format? Next to the vxl directory could be the web pages: trunk/www Additionally, we need to make sure the server side has commit hooks configured correctly. The most important is the mime-type check which makes sure every file added has a svn:mime-type property, and those that have a text-like mime-type also have svn:eol-style set. A sample script is provided on the subversion site: http://subversion.tigris.org/tools_contrib.html#check_mime_type_pl There is also one to make sure files that would conflict on a case-insensitive file system cannot be committed from a case-sensitive one: http://subversion.tigris.org/tools_contrib.html#case_insensitive_py -Brad |
From: Ian S. <ian...@st...> - 2008-08-15 14:03:29
|
Brad King wrote: > I agree with this move. However, we should be careful designing the > layout of the repository since this is our one chance to re-organize things. > > A typical layout is something like this: > > trunk/vxl > branches/vxl-x.y > tags/vxl-x.y.z > > where "x.y.z" are version numbers of course. Should we re-name the old > release branches and tags into this format? I was planning to use the trunk/branches/tags scheme. I was also planning to delete very badly named tags and branches, and to delete trivial or irrelevant one. I do not plan to rename any of the existing release tag/branch names to force them into some canonical scheme. This is going to be a big enough job as it is, and I don't really want to spend that much time on it. It is always possible to dump, edit, and import the whole repository later if you want to put in the effort. > > Additionally, we need to make sure the server side has commit hooks > configured correctly. Amitha has volunteered for this already. Ian. |
From: Brendan M. <bre...@gm...> - 2008-08-19 01:35:34
|
G'day All, Just in regards to branching and tagging etc. When I first started making releases I carefully followed the typical mechanism for making releases. Tag a branch point, make a branch, then make a release from the branched version etc. Eventually I abandoned the effort as a waste of time. Now I just tag a release version on the main trunk and don't make a branch point. I think it's worthwhile revisiting this procedure and whether it is worth branching. So what's the purpose of branching? Seems obvious to me - so it is easy to support released versions, do bug fixes etc without users having to upgrade to a new version. What's the reality in vxl? Basically, we don't support released versions at all. Released versions are really just regular (mostly) packaged up versions of the trunk. If there were a serious problem with a release that required a fix, then as the release maintainer, I'd be much more likely simply to make a new release than go and fix the old one (OK, I think I fixed one release). Why? Simply because it's less work. So I don't support going to a more complicated structure for this reason. Now, having said all that, I think we should look carefully at splitting the releases into two halves - core and contrib. It is becoming increasingly difficult to find an error-free dashboard when trying to make new releases. Most of the time, these errors occur in contrib. In fact, the core changes very slowly, whereas contrib is often used as a live experimental coding repository. To be honest, I don't really have a well developed suggestion here, and I'm not sure now is the right time to consider it - but I thought I'd mention it. I agree with Ian that perhaps we should just do the simplest thing now to convert to svn. 2008/8/16 Ian Scott <ian...@st...>: > Brad King wrote: > >> I agree with this move. However, we should be careful designing the >> layout of the repository since this is our one chance to re-organize things. >> >> A typical layout is something like this: >> >> trunk/vxl >> branches/vxl-x.y >> tags/vxl-x.y.z >> >> where "x.y.z" are version numbers of course. Should we re-name the old >> release branches and tags into this format? > > I was planning to use the trunk/branches/tags scheme. > I was also planning to delete very badly named tags and branches, and to > delete trivial or irrelevant one. I do not plan to rename any of the > existing release tag/branch names to force them into some canonical scheme. > > This is going to be a big enough job as it is, and I don't really want > to spend that much time on it. It is always possible to dump, edit, and > import the whole repository later if you want to put in the effort. > > >> >> Additionally, we need to make sure the server side has commit hooks >> configured correctly. > > Amitha has volunteered for this already. > > Ian. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > -- Cheers, Brendan |
From: Ian S. <ian...@st...> - 2009-02-16 10:11:30
|
Sorry about the delay in this work. I have done about half of the prep work for the move, refining scripts to tidy up the file-types, tags, branches, etc. I had suggested to some of you that I might get a chance this last weekend to work on it. That did not happen, and it will be at least a month before I get a chance to look at this problem again. If you are waiting for the conversion before doing some major work - I'd suggest going ahead now. Regards, Ian. Ian Scott wrote: > Brad King wrote: > >> I agree with this move. However, we should be careful designing the >> layout of the repository since this is our one chance to re-organize things. >> >> A typical layout is something like this: >> >> trunk/vxl >> branches/vxl-x.y >> tags/vxl-x.y.z >> >> where "x.y.z" are version numbers of course. Should we re-name the old >> release branches and tags into this format? > > I was planning to use the trunk/branches/tags scheme. > I was also planning to delete very badly named tags and branches, and to > delete trivial or irrelevant one. I do not plan to rename any of the > existing release tag/branch names to force them into some canonical scheme. > > This is going to be a big enough job as it is, and I don't really want > to spend that much time on it. It is always possible to dump, edit, and > import the whole repository later if you want to put in the effort. > > >> Additionally, we need to make sure the server side has commit hooks >> configured correctly. > > Amitha has volunteered for this already. > > Ian. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Brad K. <bra...@ki...> - 2009-03-11 18:20:00
Attachments:
vxl-convert.props
|
Ian Scott wrote: > Sorry about the delay in this work. > I have done about half of the prep work for the move, refining scripts > to tidy up the file-types, tags, branches, etc. I've continued this effort. Thanks for the info you sent me, Ian. > Ian Scott wrote: >> I was planning to use the trunk/branches/tags scheme. I have a conversion script mostly ready. It takes about 30 minutes on my machine. It converts both the "vxl" and "www" modules simultaneously, and uses this layout: svnroot/vxl/trunk svnroot/vxl/branches svnroot/vxl/tags svnroot/www/trunk svnroot/www/branches svnroot/www/tags >> I was also planning to delete very badly named tags and branches, and to >> delete trivial or irrelevant one. The script preserves the following tags and branches: vxl/branches/build-dsps/ vxl/branches/build-makefiles/ vxl/branches/unlabeled-1.1.2/ (cvs2svn claims a dependency on this one) vxl/branches/vxl-1-0/ vxl/branches/vxl-1-1/ vxl/branches/vxl-1-2/ vxl/branches/vxl-1-3/ vxl/branches/vxl-1-4-0/ vxl/branches/vxl-1-4/ vxl/branches/vxl-1-5-1/ vxl/branches/vxl-1-5/ vxl/branches/vxl_1-0-beta/ vxl/branches/vxl_1-2-beta-makefiles/ vxl/branches/vxl_1-2-beta/ vxl/tags/vxl-1-0-0/ vxl/tags/vxl-1-0-bp/ vxl/tags/vxl-1-1-0/ vxl/tags/vxl-1-1-bp/ vxl/tags/vxl-1-10-b1/ vxl/tags/vxl-1-11-0-b1/ vxl/tags/vxl-1-11-0-b2/ vxl/tags/vxl-1-11-0/ vxl/tags/vxl-1-12-0-b1/ vxl/tags/vxl-1-12-0/ vxl/tags/vxl-1-2-0/ vxl/tags/vxl-1-2-bp/ vxl/tags/vxl-1-3-0/ vxl/tags/vxl-1-3-bp/ vxl/tags/vxl-1-4-0-bp/ vxl/tags/vxl-1-4-bp/ vxl/tags/vxl-1-5-0/ vxl/tags/vxl-1-5-1-0/ vxl/tags/vxl-1-5-1-bp/ vxl/tags/vxl-1-5-bp/ vxl/tags/vxl-1-6-0/ vxl/tags/vxl-1-7-0/ vxl/tags/vxl-1-8-0/ vxl/tags/vxl-1-8-b1/ vxl/tags/vxl-1-8-b2/ vxl/tags/vxl-1-9-0/ vxl/tags/vxl-1-9-b1/ www/branches/vxl-1-5/ www/tags/vxl-1-11-0-b1/ www/tags/vxl-1-11-0-b2/ www/tags/vxl-1-11-0/ www/tags/vxl-1-12-0-b1/ www/tags/vxl-1-12-0/ www/tags/vxl-1-5-0/ www/tags/vxl-1-5-bp/ Does anyone know whether we need to bother keeping the "-bp" tags? I'll investigate how svn tracks branch points. I bet we don't need the tags. (This doesn't affect the conversion because cvs2svn seems to want all the -bp tags since other tags 'depend' on them, but we can delete the directories from future revisions after the final conversion.) I'm also considering renaming "vxl-a-b-c" to "vxl-a.b.c" since they look nicer as directory names and that's probably how we'll want to do future tags and branches. Comments? I dropped these branches (the iup branches cover only pieces of the tree): agap-new-cmake-test-bp ge_vxl_dev iup_3-0-branch iup_3-1-branch iup_4-0-branch iup_4-1-branch iup_4-2-branch iup_5-0-beta omg-jun-02 OTAGO target VanDuc-2002-01-08-Branch Instead of fixing up the executable permissions of ,v files I disabled cvs2svn's automatic executable bit and instead set up auto-props to make the proper files executable. I determined which files to make executable by looking at those with executable permission in cvs and grepping out files I know should not be executable (like sources). In vxl/trunk the following files are executable: vxl/config/cmake/DSPTemplates/mex/configure vxl/config/cmake/DSPTemplates/mex/install-sh vxl/configure vxl/core/bin/buildlog_parser.pl vxl/core/bin/check_consistency vxl/core/bin/check_dsp vxl/core/bin/check_malindentation.pl vxl/core/bin/ref_to_sptr.pl vxl/core/bin/sync_co.sh vxl/core/bin/vgui_make_sptr.pl vxl/core/bin/vxl_convert.pl vxl/core/bin/vxl_demangle vxl/core/bin/vxl_env vxl/core/bin/vxl_filter.pl vxl/core/bin/vxl_make_dll_h.pl vxl/core/bin/vxl_rm_copyright_filt.pl vxl/core/bin/vxl_version_update.sh vxl/core/doc/vxl_doxy.pl vxl/core/tests/make_test_config.pl vxl/core/vgui/doc/vgui_users_guide/script vxl/core/vil/scripts/convertvil2tovil.run_me_second.pl vxl/core/vil/scripts/convertviltovil1.run_me_first.pl vxl/core/vil/scripts/vil1tovil.pl vxl/scripts/convert_old_to_new.pl vxl/scripts/doxy/build_all_doc.pl vxl/scripts/doxy/checkout_packages.pl vxl/scripts/doxy/gen_all_doxy.pl vxl/scripts/doxy/gen_books.pl vxl/scripts/doxy/gen_doxy_index.pl vxl/scripts/doxy/rundoxy.pl vxl/scripts/doxy/update_webserver.pl vxl/v3p/mpeg2/configure vxl/v3p/netlib/libf2c/comptry.bat vxl/v3p/netlib/libf2c/scomptry.bat vxl/v3p/tiff_install.pl vxl/vcl/generic/zap.pl vxl/vcl/iso/generate.sh vxl/vcl/tr1/generate.sh Every imported file has the svn:mime-type property set according to its extension. All relevant files have svn:eol-style set as follows: native = most text files and sources LF = shell scripts CRLF = bat files and VS project files I manually verified that all the eol-style settings make sense, and sampled files with non-trivial mime-types. I've attached the auto-props file I'm using to set mime-types. Most files are handled by /etc/mime.types, so this is just the left-over ones. I've checked out vxl/trunk and www/trunk from both svn and cvs and done a "diff -w -r -x CVS -x .svn" to see that the trees are identical (except for some $Log$ and $Id$ cvs tags). I also tested the vxl-1-0 branch and the vxl-1-12-0 tags, which are identical too. I think this takes care of everything. Does anyone see something I'm missing? Thanks, -Brad |
From: Brad K. <bra...@ki...> - 2009-03-11 20:07:48
|
Brad King wrote: > Does anyone know whether we need to bother keeping the "-bp" tags? I'll > investigate how svn tracks branch points. I bet we don't need the tags. We don't need the branch point tags, so I'm excluding them. Subversion can provide the source of the 'copy' that created a branch or tag: $ svn log <svnroot>/vxl/tags/vxl-1.1.0 -l 1 -v --xml ... <path copyfrom-path="/vxl/branches/vxl-1.1" copyfrom-rev="12947" action="A">/vxl/tags/vxl-1.1.0</path> ... > I'm also considering renaming "vxl-a-b-c" to "vxl-a.b.c" since they > look nicer as directory names and that's probably how we'll want to > do future tags and branches. Comments? This was easy, and there was even an example already provided in the cvs2svn documentation that does exactly this. -Brad |
From: Brad K. <bra...@ki...> - 2009-03-11 20:57:16
|
Brad King wrote: > Brad King wrote: >> Does anyone know whether we need to bother keeping the "-bp" tags? I'll >> investigate how svn tracks branch points. I bet we don't need the tags. > > We don't need the branch point tags, so I'm excluding them. [snip] >> I'm also considering renaming "vxl-a-b-c" to "vxl-a.b.c" since they >> look nicer as directory names and that's probably how we'll want to >> do future tags and branches. Comments? > > This was easy, and there was even an example already provided in the cvs2svn > documentation that does exactly this. I now have these tags/branches: vxl/branches/build-dsps/ vxl/branches/build-makefiles/ vxl/branches/unlabeled-1.1.2/ vxl/branches/vxl-1.0-beta/ vxl/branches/vxl-1.0/ vxl/branches/vxl-1.1/ vxl/branches/vxl-1.2-beta-makefiles/ vxl/branches/vxl-1.2-beta/ vxl/branches/vxl-1.2/ vxl/branches/vxl-1.3/ vxl/branches/vxl-1.4/ vxl/branches/vxl-1.5.1/ vxl/branches/vxl-1.5/ vxl/tags/vxl-1.0.0/ vxl/tags/vxl-1.1.0/ vxl/tags/vxl-1.10-b1/ vxl/tags/vxl-1.11.0-b1/ vxl/tags/vxl-1.11.0-b2/ vxl/tags/vxl-1.11.0/ vxl/tags/vxl-1.12.0-b1/ vxl/tags/vxl-1.12.0/ vxl/tags/vxl-1.2.0/ vxl/tags/vxl-1.3.0/ vxl/tags/vxl-1.4.0/ vxl/tags/vxl-1.5.0/ vxl/tags/vxl-1.5.1.0/ vxl/tags/vxl-1.6.0/ vxl/tags/vxl-1.7.0/ vxl/tags/vxl-1.8-b1/ vxl/tags/vxl-1.8-b2/ vxl/tags/vxl-1.8.0/ vxl/tags/vxl-1.9-b1/ vxl/tags/vxl-1.9.0/ www/branches/vxl-1.5/ www/tags/vxl-1.11.0-b1/ www/tags/vxl-1.11.0-b2/ www/tags/vxl-1.11.0/ www/tags/vxl-1.12.0-b1/ www/tags/vxl-1.12.0/ www/tags/vxl-1.5.0/ -Brad |
From: Brendan M. <bre...@gm...> - 2009-03-11 21:39:43
|
Looks good to me. We definitely don't need the bp tags - I had done away with them several releases ago ... 2009/3/12 Brad King <bra...@ki...>: > Brad King wrote: >> Brad King wrote: >>> Does anyone know whether we need to bother keeping the "-bp" tags? I'll >>> investigate how svn tracks branch points. I bet we don't need the tags. >> >> We don't need the branch point tags, so I'm excluding them. > [snip] >>> I'm also considering renaming "vxl-a-b-c" to "vxl-a.b.c" since they >>> look nicer as directory names and that's probably how we'll want to >>> do future tags and branches. Comments? >> >> This was easy, and there was even an example already provided in the cvs2svn >> documentation that does exactly this. > > I now have these tags/branches: > > vxl/branches/build-dsps/ > vxl/branches/build-makefiles/ > vxl/branches/unlabeled-1.1.2/ > vxl/branches/vxl-1.0-beta/ > vxl/branches/vxl-1.0/ > vxl/branches/vxl-1.1/ > vxl/branches/vxl-1.2-beta-makefiles/ > vxl/branches/vxl-1.2-beta/ > vxl/branches/vxl-1.2/ > vxl/branches/vxl-1.3/ > vxl/branches/vxl-1.4/ > vxl/branches/vxl-1.5.1/ > vxl/branches/vxl-1.5/ > vxl/tags/vxl-1.0.0/ > vxl/tags/vxl-1.1.0/ > vxl/tags/vxl-1.10-b1/ > vxl/tags/vxl-1.11.0-b1/ > vxl/tags/vxl-1.11.0-b2/ > vxl/tags/vxl-1.11.0/ > vxl/tags/vxl-1.12.0-b1/ > vxl/tags/vxl-1.12.0/ > vxl/tags/vxl-1.2.0/ > vxl/tags/vxl-1.3.0/ > vxl/tags/vxl-1.4.0/ > vxl/tags/vxl-1.5.0/ > vxl/tags/vxl-1.5.1.0/ > vxl/tags/vxl-1.6.0/ > vxl/tags/vxl-1.7.0/ > vxl/tags/vxl-1.8-b1/ > vxl/tags/vxl-1.8-b2/ > vxl/tags/vxl-1.8.0/ > vxl/tags/vxl-1.9-b1/ > vxl/tags/vxl-1.9.0/ > www/branches/vxl-1.5/ > www/tags/vxl-1.11.0-b1/ > www/tags/vxl-1.11.0-b2/ > www/tags/vxl-1.11.0/ > www/tags/vxl-1.12.0-b1/ > www/tags/vxl-1.12.0/ > www/tags/vxl-1.5.0/ > > -Brad > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > -- Cheers, Brendan |
From: Brad K. <bra...@ki...> - 2009-03-12 15:46:32
|
Brendan McCane wrote: > Looks good to me. We definitely don't need the bp tags - I had done > away with them several releases ago ... I've migrated a *practice* conversion to sourceforge: http://vxl.svn.sourceforge.net/viewvc/vxl/ This is *not* the final conversion, and the entire repository will be replaced when the final conversion is done. If anyone has time to try out the repo, please do so and send comments. Feel free to commit toy changes to it, but remember that this will all be wiped out when we do the final conversion. Anonymous checkout: svn co http://vxl.svn.sourceforge.net/svnroot/vxl/vxl/trunk vxl svn co http://vxl.svn.sourceforge.net/svnroot/vxl/vxl/tags/vxl-1.12.0 svn co http://vxl.svn.sourceforge.net/svnroot/vxl/www/trunk www For developer checkout, use https instead of http. -Brad P.S. I deleted that 'unlabeled-1.1.2' branch that cvs2svn refused to drop: svn rm https://vxl.svn.sourceforge.net/svnroot/vxl/vxl/branches/unlabeled-1.1.2 However, I think I might be able to drop it in the next conversion with a "symbol hint" to cvs2svn. |
From: Peter V. <pet...@ya...> - 2009-03-12 20:31:30
|
Good piece of work, Brad! That means I'll have to start learning svn; never used it before. Always had good experiences with CVS, but heard very good things about svn. Concerning timings: I'm currently running an "svn co" on CYGWIN (which is always somewhat slower than Linux, also for CVS). It took 15 minutes for just downloading brl/bmvl and brl/bseg, and 10 more minutes to finish brl, so I'm holding my breath... About the remark by Fred Wheeler about "cvs diff" vs "svn diff": also CVS does not contact the repository for files with a timestamp not more recent than what's stored in the corresponding CVS/Entries file. -- Peter. __________________________________________________________ Går det långsamt? Skaffa dig en snabbare bredbandsuppkoppling. Sök och jämför priser hos Kelkoo. http://www.kelkoo.se/c-100015813-bredband.html?partnerId=96914325 |
From: Peter V. <pet...@ya...> - 2009-03-12 21:21:19
|
OK, the full "svn co" (just https://vxl.svn.sourceforge.net/svnroot/vxl/vxl/trunk) took exactly 1 hour. -- Peter. __________________________________________________________ Går det långsamt? Skaffa dig en snabbare bredbandsuppkoppling. Sök och jämför priser hos Kelkoo. http://www.kelkoo.se/c-100015813-bredband.html?partnerId=96914325 |
From: Ian S. <ian...@st...> - 2009-03-13 09:56:10
|
Our experience with the CVS to SVN conversion of out internal repository is that checkout and commit is about twice as slow. Updates are faster - 3-4 times faster when there have been no changes at either end. I also have never seen anything equivalent to the common CVS lock contention messages when several people (or more likely dashboard clients) are updating at the same time. The advantages of not having to contact the server for straight forward diff and stat isn't so obvious on our locally networked repository, but should be significant using SF. Ian. |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2009-03-13 10:21:15
|
On Fri, Mar 13, 2009 at 5:56 AM, Ian Scott wrote: > Our experience with the CVS to SVN conversion of out internal repository > is that checkout and commit is about twice as slow. Updates are faster - > 3-4 times faster when there have been no changes at either end. I also > have never seen anything equivalent to the common CVS lock contention > messages when several people (or more likely dashboard clients) are > updating at the same time. That would seem ok (i.e., twice as slow), but the current slowness seems to me that is uncommon... I opened a ticket for support at sourceforge in case it has something to do with a current problem. I'll report back if they clear things up. > The advantages of not having to contact the server for straight forward > diff and stat isn't so obvious on our locally networked repository, but > should be significant using SF. I agree that even now, it is a good move. --Miguel |
From: Ian S. <ian...@st...> - 2009-03-24 13:05:36
|
Peter Vanroose wrote: > OK, the full "svn co" (just https://vxl.svn.sourceforge.net/svnroot/vxl/vxl/trunk) took exactly 1 hour. This may just have been a temporary sourceforge problem I just checked out vxl in under 5 minutes. svn co --username=scottim \ https://vxl.svn.sourceforge.net/svnroot/vxl/trunk src |
From: Matthew L. <mat...@gm...> - 2009-03-11 18:40:13
|
Brad, Everything looks good to me, but I don't know enough about the inner workings of CVS and SVN to know if you might have missed anything. Since you have taken this over from Ian, do I understand correctly that you plan to complete the conversion in the near future? Do you have a time frame for this yet? What do the rest of us need to do to make this switch easier? I imagine you will want us to stop committing changes to CVS at some point. If you see this happening soon, I will continue to hold off on moving vidl2 into core. Thanks, Matt On Mar 11, 2009, at 2:19 PM, Brad King wrote: > Ian Scott wrote: >> Sorry about the delay in this work. >> I have done about half of the prep work for the move, refining >> scripts to tidy up the file-types, tags, branches, etc. > > I've continued this effort. Thanks for the info you sent me, Ian. > >> Ian Scott wrote: >>> I was planning to use the trunk/branches/tags scheme. > > I have a conversion script mostly ready. It takes about 30 minutes > on my > machine. It converts both the "vxl" and "www" modules > simultaneously, and > uses this layout: > > svnroot/vxl/trunk > svnroot/vxl/branches > svnroot/vxl/tags > svnroot/www/trunk > svnroot/www/branches > svnroot/www/tags > >>> I was also planning to delete very badly named tags and branches, >>> and to delete trivial or irrelevant one. > > The script preserves the following tags and branches: > > vxl/branches/build-dsps/ > vxl/branches/build-makefiles/ > vxl/branches/unlabeled-1.1.2/ (cvs2svn claims a dependency on this > one) > vxl/branches/vxl-1-0/ > vxl/branches/vxl-1-1/ > vxl/branches/vxl-1-2/ > vxl/branches/vxl-1-3/ > vxl/branches/vxl-1-4-0/ > vxl/branches/vxl-1-4/ > vxl/branches/vxl-1-5-1/ > vxl/branches/vxl-1-5/ > vxl/branches/vxl_1-0-beta/ > vxl/branches/vxl_1-2-beta-makefiles/ > vxl/branches/vxl_1-2-beta/ > vxl/tags/vxl-1-0-0/ > vxl/tags/vxl-1-0-bp/ > vxl/tags/vxl-1-1-0/ > vxl/tags/vxl-1-1-bp/ > vxl/tags/vxl-1-10-b1/ > vxl/tags/vxl-1-11-0-b1/ > vxl/tags/vxl-1-11-0-b2/ > vxl/tags/vxl-1-11-0/ > vxl/tags/vxl-1-12-0-b1/ > vxl/tags/vxl-1-12-0/ > vxl/tags/vxl-1-2-0/ > vxl/tags/vxl-1-2-bp/ > vxl/tags/vxl-1-3-0/ > vxl/tags/vxl-1-3-bp/ > vxl/tags/vxl-1-4-0-bp/ > vxl/tags/vxl-1-4-bp/ > vxl/tags/vxl-1-5-0/ > vxl/tags/vxl-1-5-1-0/ > vxl/tags/vxl-1-5-1-bp/ > vxl/tags/vxl-1-5-bp/ > vxl/tags/vxl-1-6-0/ > vxl/tags/vxl-1-7-0/ > vxl/tags/vxl-1-8-0/ > vxl/tags/vxl-1-8-b1/ > vxl/tags/vxl-1-8-b2/ > vxl/tags/vxl-1-9-0/ > vxl/tags/vxl-1-9-b1/ > www/branches/vxl-1-5/ > www/tags/vxl-1-11-0-b1/ > www/tags/vxl-1-11-0-b2/ > www/tags/vxl-1-11-0/ > www/tags/vxl-1-12-0-b1/ > www/tags/vxl-1-12-0/ > www/tags/vxl-1-5-0/ > www/tags/vxl-1-5-bp/ > > Does anyone know whether we need to bother keeping the "-bp" tags? > I'll > investigate how svn tracks branch points. I bet we don't need the > tags. > (This doesn't affect the conversion because cvs2svn seems to want all > the -bp tags since other tags 'depend' on them, but we can delete the > directories from future revisions after the final conversion.) > > I'm also considering renaming "vxl-a-b-c" to "vxl-a.b.c" since they > look nicer as directory names and that's probably how we'll want to > do future tags and branches. Comments? > > I dropped these branches (the iup branches cover only pieces of the > tree): > > agap-new-cmake-test-bp > ge_vxl_dev > iup_3-0-branch > iup_3-1-branch > iup_4-0-branch > iup_4-1-branch > iup_4-2-branch > iup_5-0-beta > omg-jun-02 > OTAGO > target > VanDuc-2002-01-08-Branch > > Instead of fixing up the executable permissions of ,v files I disabled > cvs2svn's automatic executable bit and instead set up auto-props to > make the proper files executable. I determined which files to make > executable by looking at those with executable permission in cvs and > grepping out files I know should not be executable (like sources). > In vxl/trunk the following files are executable: > > vxl/config/cmake/DSPTemplates/mex/configure > vxl/config/cmake/DSPTemplates/mex/install-sh > vxl/configure > vxl/core/bin/buildlog_parser.pl > vxl/core/bin/check_consistency > vxl/core/bin/check_dsp > vxl/core/bin/check_malindentation.pl > vxl/core/bin/ref_to_sptr.pl > vxl/core/bin/sync_co.sh > vxl/core/bin/vgui_make_sptr.pl > vxl/core/bin/vxl_convert.pl > vxl/core/bin/vxl_demangle > vxl/core/bin/vxl_env > vxl/core/bin/vxl_filter.pl > vxl/core/bin/vxl_make_dll_h.pl > vxl/core/bin/vxl_rm_copyright_filt.pl > vxl/core/bin/vxl_version_update.sh > vxl/core/doc/vxl_doxy.pl > vxl/core/tests/make_test_config.pl > vxl/core/vgui/doc/vgui_users_guide/script > vxl/core/vil/scripts/convertvil2tovil.run_me_second.pl > vxl/core/vil/scripts/convertviltovil1.run_me_first.pl > vxl/core/vil/scripts/vil1tovil.pl > vxl/scripts/convert_old_to_new.pl > vxl/scripts/doxy/build_all_doc.pl > vxl/scripts/doxy/checkout_packages.pl > vxl/scripts/doxy/gen_all_doxy.pl > vxl/scripts/doxy/gen_books.pl > vxl/scripts/doxy/gen_doxy_index.pl > vxl/scripts/doxy/rundoxy.pl > vxl/scripts/doxy/update_webserver.pl > vxl/v3p/mpeg2/configure > vxl/v3p/netlib/libf2c/comptry.bat > vxl/v3p/netlib/libf2c/scomptry.bat > vxl/v3p/tiff_install.pl > vxl/vcl/generic/zap.pl > vxl/vcl/iso/generate.sh > vxl/vcl/tr1/generate.sh > > Every imported file has the svn:mime-type property set according > to its extension. All relevant files have svn:eol-style set as > follows: > > native = most text files and sources > LF = shell scripts > CRLF = bat files and VS project files > > I manually verified that all the eol-style settings make sense, > and sampled files with non-trivial mime-types. I've attached > the auto-props file I'm using to set mime-types. Most files are > handled by /etc/mime.types, so this is just the left-over ones. > > I've checked out vxl/trunk and www/trunk from both svn and cvs > and done a "diff -w -r -x CVS -x .svn" to see that the trees > are identical (except for some $Log$ and $Id$ cvs tags). I also > tested the vxl-1-0 branch and the vxl-1-12-0 tags, which are > identical too. > > I think this takes care of everything. Does anyone see something > I'm missing? > > Thanks, > -Brad > [auto-props] > # Binary files > *.apm = svn:mime-type=application/octet- > stream > *.bfs = svn:mime-type=application/octet- > stream > *.bin = svn:mime-type=application/octet- > stream > *.bvl = svn:mime-type=application/octet- > stream > *.cnx = svn:mime-type=application/octet- > stream > *.dcm = svn:mime-type=application/octet- > stream > *.docx = svn:mime-type=application/ > vnd.openxmlformats-officedocument.wordprocessingml.document > *.esf = svn:mime-type=application/octet- > stream > *.gipl = svn:mime-type=application/octet- > stream > *.hdr = svn:mime-type=application/octet- > stream > *.img = svn:mime-type=application/octet- > stream > *.iris = svn:mime-type=application/octet- > stream > *.j2k = svn:mime-type=application/octet- > stream > *.mit = svn:mime-type=application/octet- > stream > *.nitf = svn:mime-type=application/octet- > stream > *.nsif = svn:mime-type=application/octet- > stream > *.ntf = svn:mime-type=application/octet- > stream > *.ras = svn:mime-type=application/octet- > stream > *.v3i = svn:mime-type=application/octet- > stream > *.viff = svn:mime-type=application/octet- > stream > > # Windows files > *.bat = svn:mime-type=application/x-msdos- > program;svn:eol-style=CRLF;svn:executable > *.clw = svn:mime-type=text/plain;svn:eol- > style=CRLF > *.dsp = svn:mime-type=text/plain;svn:eol- > style=CRLF > *.dsp.keep = svn:mime-type=text/plain;svn:eol- > style=CRLF > *.dsptemplate = svn:mime-type=text/plain;svn:eol- > style=CRLF > *.dsw = svn:mime-type=text/plain;svn:eol- > style=CRLF > *.dsw.keep = svn:mime-type=text/plain;svn:eol- > style=CRLF > *.rc = svn:mime-type=text/plain;svn:eol- > style=CRLF > *.rc2 = svn:mime-type=text/plain;svn:eol- > style=CRLF > > # Text files > *.NoDartCoverage = svn:mime-type=text/plain > *.README = svn:mime-type=text/plain > *.URL = svn:mime-type=text/plain > *.cmake = svn:mime-type=text/plain > *.cmake.in = svn:mime-type=text/plain > *.def = svn:mime-type=text/plain > *.fl = svn:mime-type=text/plain > *.hhh = svn:mime-type=text/plain > *.incl = svn:mime-type=text/plain > *.m4 = svn:mime-type=text/plain > *.notes = svn:mime-type=text/plain > *.ply = svn:mime-type=text/plain > CHANGES* = svn:mime-type=text/plain > COPYING = svn:mime-type=text/plain > COPYRIGHT = svn:mime-type=text/plain > ChangeLog* = svn:mime-type=text/plain > FAQ = svn:mime-type=text/plain > FORCEBUILD = svn:mime-type=text/plain > GETTING_STARTED = svn:mime-type=text/plain > HISTORY = svn:mime-type=text/plain > INSTALL = svn:mime-type=text/plain > LICENSE = svn:mime-type=text/plain > README* = svn:mime-type=text/plain > TODO = svn:mime-type=text/plain > > # Source files > *.C = svn:mime-type=text/x-c++src > *.Cpp = svn:mime-type=text/x-c++src > *.H = svn:mime-type=text/x-chdr > *.P = svn:mime-type=text/x-chdr > *.cxx.in = svn:mime-type=text/x-c++src > *.f = svn:mime-type=text/x-fortran-src > *.h0 = svn:mime-type=text/x-chdr > *.h.in = svn:mime-type=text/x-chdr > *.h.vc = svn:mime-type=text/x-chdr > *.inc = svn:mime-type=text/x-chdr > *.tcc = svn:mime-type=text/x-c++src > *.txx = svn:mime-type=text/x-c++src > > # Build files > *.mk = svn:mime-type=text/x-makefile > *.mk.in = svn:mime-type=text/x-makefile > Makefile* = svn:mime-type=text/x-makefile > makefile = svn:mime-type=text/x-makefile > makefile* = svn:mime-type=text/x-makefile > SConstruct = svn:mime-type=text/x-python > > # Script files > *.pl = svn:mime-type=text/x- > perl;svn:executable > *.sh = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > check_consistency = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > check_dsp = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > check_syntax = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > configure = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > configure.in = svn:mime-type=text/x-sh;svn:eol- > style=LF > install-sh = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > script = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > vxl_demangle = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > vxl_env = svn:mime-type=text/x-sh;svn:eol- > style=LF;svn:executable > > # Text-format documents > *.3 = svn:mime-type=text/plain;svn:eol- > style=LF > *.5 = svn:mime-type=text/plain;svn:eol- > style=LF > *.texi = svn:mime-type=application/x- > texinfo;svn:eol-style=native > *.xml = svn:mime-type=application/ > xml;svn:eol-style=native > > # Other files > 07JAN27.RPB = svn:mime-type=text/plain > A.poly = svn:mime-type=text/plain > Doxyfile.XXX = svn:mime-type=text/plain > Doxyfile_for_vxl_doc_rules = svn:mime-type=text/plain > Notice = svn:mime-type=text/plain > blah = svn:mime-type=text/plain > blah_tr1 = svn:mime-type=text/plain > bun000.txt.out = svn:mime-type=text/plain > bun045.txt.out = svn:mime-type=text/plain > crosscut.xrc = svn:mime-type=application/ > xml;svn:eol-style=native > data_3x3_matrix = svn:mime-type=text/plain > def_params.dat = svn:mime-type=text/plain > dicom.dic = svn:mime-type=text/plain > example_data.gx = svn:mime-type=text/plain > f2ch.add = svn:mime-type=text/x-chdr > headers.iso = svn:mime-type=text/plain > homography2d_fit_20.dat = svn:mime-type=text/plain > index.dox = svn:mime-type=text/html > init-needing-dbicp = svn:mime-type=text/plain > libf2c.lbc = svn:mime-type=text/plain > libf2c.sy = svn:mime-type=text/plain > line_fit_30.dat = svn:mime-type=text/plain > line_fit_60.dat = svn:mime-type=text/plain > math.hvc = svn:mime-type=text/x-chdr > mkfile.plan9 = svn:mime-type=text/x-makefile > names = svn:mime-type=text/plain > overlays = svn:mime-type=text/plain > point_correspondences.left = svn:mime-type=text/plain > point_correspondences.right = svn:mime-type=text/plain > pop.cd = svn:mime-type=text/plain > rpc_registration_camera.rpb = svn:mime-type=text/plain > test.wrl = svn:mime-type=x-world/x- > vrml;svn:eol-style=native > v3p_tag = svn:mime-type=text/plain > valgrind.supp = svn:mime-type=text/plain > vcl_config_stlcomp.h.vc50 = svn:mime-type=text/x-chdr > vcl_rel_ops.not = svn:mime-type=text/x-chdr > vcl_strstream.not = svn:mime-type=text/x-chdr > vtol.dtd = svn:mime-type=application/ > xml;svn:eol-style=native > wx_xrc.xrc = svn:mime-type=application/ > xml;svn:eol-style=native > xsum0.out = svn:mime-type=text/plain > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com_______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Brad K. <bra...@ki...> - 2009-03-11 18:47:40
|
Matthew Leotta wrote: > Everything looks good to me, but I don't know enough about the inner > workings of CVS and SVN to know if you might have missed anything. Okay. > Since you have taken this over from Ian, do I understand correctly that > you plan to complete the conversion in the near future? Do you have a > time frame for this yet? What do the rest of us need to do to make this > switch easier? I imagine you will want us to stop committing changes to > CVS at some point. If you see this happening soon, I will continue to > hold off on moving vidl2 into core. I do plan to finish soon, probably sometime in the next week or two. Once I'm confident the conversion script is ready I'll announce a time at which we will disable cvs commits to start the final conversion. While the conversion script is almost ready, there are still a few more details. I need to work out how to upload the converted repository to sourceforge and enable the proper commit checks. We should also let a few maintainers try out the new repo before we open it for commit. Finally, dashboard clients will need to switch to following the svn repo. -Brad |
From: Brad K. <bra...@ki...> - 2009-03-12 16:57:03
|
Brad King wrote: > I deleted that 'unlabeled-1.1.2' branch that cvs2svn refused to drop: > > svn rm https://vxl.svn.sourceforge.net/svnroot/vxl/vxl/branches/unlabeled-1.1.2 > > However, I think I might be able to drop it in the next conversion with a > "symbol hint" to cvs2svn. Since the symbol does not actually come from a cvs file cvs2svn won't let us touch it. I cannot even rename it, so we'll have to go with the above removal approach after the final conversion. I realized that the www module tags should be named 'vxl-www-a.b.c' instead of 'vxl-a.b.c' to avoid confusion with the vxl module tree on checkout. Consider svn co http://vxl.svn.sourceforge.net/svnroot/vxl/www/tags/vxl-1.12.0 versus svn co http://vxl.svn.sourceforge.net/svnroot/vxl/www/tags/vxl-www-1.12.0 The default directory name for the former is 'vxl-1.12.0' even though it is web pages, thus motivating the latter. My conversion now has this set of directories in the repo: vxl/branches/unlabeled-1.1.2/ (to be deleted after migration) vxl/branches/vxl-1.0-beta/ vxl/branches/vxl-1.0/ vxl/branches/vxl-1.1/ vxl/branches/vxl-1.2-beta-makefiles/ vxl/branches/vxl-1.2-beta/ vxl/branches/vxl-1.2/ vxl/branches/vxl-1.3/ vxl/branches/vxl-1.4/ vxl/branches/vxl-1.5.1/ vxl/branches/vxl-1.5/ vxl/branches/vxl-build-dsps/ vxl/branches/vxl-build-makefiles/ vxl/tags/vxl-1.0.0/ vxl/tags/vxl-1.1.0/ vxl/tags/vxl-1.10-b1/ vxl/tags/vxl-1.11.0-b1/ vxl/tags/vxl-1.11.0-b2/ vxl/tags/vxl-1.11.0/ vxl/tags/vxl-1.12.0-b1/ vxl/tags/vxl-1.12.0/ vxl/tags/vxl-1.2.0/ vxl/tags/vxl-1.3.0/ vxl/tags/vxl-1.4.0/ vxl/tags/vxl-1.5.0/ vxl/tags/vxl-1.5.1.0/ vxl/tags/vxl-1.6.0/ vxl/tags/vxl-1.7.0/ vxl/tags/vxl-1.8-b1/ vxl/tags/vxl-1.8-b2/ vxl/tags/vxl-1.8.0/ vxl/tags/vxl-1.9-b1/ vxl/tags/vxl-1.9.0/ vxl/trunk/ www/branches/vxl-www-1.5/ www/tags/vxl-www-1.11.0-b1/ www/tags/vxl-www-1.11.0-b2/ www/tags/vxl-www-1.11.0/ www/tags/vxl-www-1.12.0-b1/ www/tags/vxl-www-1.12.0/ www/tags/vxl-www-1.5.0/ www/trunk/ -Brad |
From: Amitha P. <ami...@us...> - 2009-03-12 18:09:53
|
I just tried a couple of svn operations: checkout, update, log, diff, and commit. The subversion response seems to be significantly slower than the cvs response. Did anyone else have this issue? Amitha. |
From: Matthew L. <mat...@gm...> - 2009-03-12 18:33:59
|
I did a checkout and it seemed slow. So I decided to do another checkout and time it. It seems even slower now (still running). It seems to go in quick bursts and then pauses for a few seconds. Could this be because we have many people testing it all at once? Matt On Mar 12, 2009, at 2:09 PM, Amitha Perera wrote: > I just tried a couple of svn operations: checkout, update, log, diff, > and commit. The subversion response seems to be significantly slower > than the cvs response. Did anyone else have this issue? > > Amitha. > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Antonio G. C. <A.G...@de...> - 2009-03-12 19:17:40
|
Some days ago, I did a chechout for other software (voreen, http://svn.voreen.org). I had to run the command several times because it seemed to stop downloading. I thought the problem was the number of people downloading... Now, your mail makes me think that svn is slower in any case... Antonio P.S. BTW, In my case, it is also slower than cvs Matthew Leotta escribió: > I did a checkout and it seemed slow. So I decided to do another > checkout and time it. It seems even slower now (still running). It > seems to go in quick bursts and then pauses for a few seconds. Could > this be because we have many people testing it all at once? > > Matt > > > On Mar 12, 2009, at 2:09 PM, Amitha Perera wrote: > > >> I just tried a couple of svn operations: checkout, update, log, diff, >> and commit. The subversion response seems to be significantly slower >> than the cvs response. Did anyone else have this issue? >> >> Amitha. >> >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >> are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly >> and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Wheeler, F. W (G. Research) <wh...@cr...> - 2009-03-12 19:09:28
|
I was just doing my first svn checkout. I also noticed that the checkout is slower. I'll get some times. Fred > -----Original Message----- > From: Amitha Perera [mailto:ami...@us...] > Sent: Thursday, March 12, 2009 2:09 PM > To: Brad King > Cc: Vxl-maintainers > Subject: Re: [Vxl-maintainers] CVS->subversion delay. > > I just tried a couple of svn operations: checkout, update, > log, diff, and commit. The subversion response seems to be > significantly slower than the cvs response. Did anyone else > have this issue? > > Amitha. > > > -------------------------------------------------------------- > ---------------- > Apps built with the Adobe(R) Flex(R) framework and Flex > Builder(TM) are powering Web 2.0 with engaging, > cross-platform capabilities. Quickly and easily build your > RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. > http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Amitha P. <ami...@us...> - 2009-03-12 18:47:06
|
Is this a good time to look into other hosts? E.g. Google code? Amitha. |
From: Brad K. <bra...@ki...> - 2009-03-12 18:53:05
|
Amitha Perera wrote: > Is this a good time to look into other hosts? E.g. Google code? I'm not sure it's the host. Other projects have had this problem: http://svn.haxx.se/users/archive-2005-04/0071.shtml It looks like checkout may be slower by the most, and other operations are not as bad (certainly local diff is faster). -Brad |