From: Wheeler, F. W (Research) <wh...@cr...> - 2003-06-02 21:17:38
|
I'm not making the change from my previous e-mail (below). My mistake. It seems that, because the repository was directly modified, "cvs update" is not enough to get the latest vil. vil/io/CMakeLists.txt -> vil1/io/CMakeLists.txt was at version 1.7 and the latest vil2/io/CMakeLists.txt -> vil/io/CMakeLists.txt is also at version 1.7, so my checkout thinks it has the latest version. That's why all the dashboards have the same incorrect vil/io/CMakeLists.txt, as Peter noted. I guess it is advisable to completely remove core/vil before updating. Fred Wheeler > -----Original Message----- > From: Wheeler, Frederick W (Research) [mailto:wh...@cr...] > Sent: Monday, June 02, 2003 3:30 PM > To: 'Pet...@es...'; Ian Scott > Cc: Vxl-maintainers (E-mail) > Subject: RE: [Vxl-maintainers] VXL repository now open > > > > Looks like core/vil/io/CMakeLists.txt is incorrect in the > repository. The > CML file lists some non-existant files. I'm about to commit > a fix. I just > want to make sure vil links for me first. > > Fred Wheeler > > > > -----Original Message----- > > From: Peter Vanroose [mailto:Pet...@es...] > > Sent: Monday, June 02, 2003 5:23 AM > > To: Ian Scott > > Cc: Vxl-maintainers (E-mail) > > Subject: Re: [Vxl-maintainers] VXL repository now open > > > > > > However, the dashboard is not yet fully green, although it > > should, I believe. > > Cause: apparently an incorrect cvs update of the file > > core/vil/io/CMakeLists.txt > > (at least, that's what I understand from the error messages). > > This applies to both Manchester and CRD dashboard entries. > > Could someone manually check and possibly re-run the nightly > > for today? > > > > > > -- Peter. > > > > > > P.S. The Leuven nightly submissions for today will be > later, due to an > > extended electricity maintainance in the building this > morning... > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay! > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Vxl-maintainers mailing list > > Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Geoffrey C. <ge...@vi...> - 2003-06-03 09:13:36
|
Fred Wheeler says: > It seems that, because the repository was directly modified, "cvs = update" > is > not enough to get the latest vil. vil/io/CMakeLists.txt -> > vil1/io/CMakeLists.txt was at version 1.7 and the latest > vil2/io/CMakeLists.txt -> vil/io/CMakeLists.txt is also at version = 1.7, so > my checkout thinks it has the latest version. That's why all the > dashboards > have the same incorrect vil/io/CMakeLists.txt, as Peter noted. I've had a couple of personal complaints over the last few days about = the cvs repository fiddling which was necessary in order to do the recent vil/vil1/vil2 move. It is clear that there is a significant hole in the capabilities of cvs = as it is not possible to move a file whilst maintaining the log entries. = The method which has recently been adopted, and adopted in a number of cases = in the past, is to 'hack' around directly within the repository in order to perform these changes. Whilst this method does perform the prerequisite 'move' it does cause a number of problems for old checkouts and often = the only sensible solution is to perform a new checkout and start from scratch[1]. Don't forget that a large number of vxl users are, indeed, 'users' and are not cvs experts. Clearly the move has caused havoc with = the dashboard. And (whilst I know it is not recommended) I believe there = are still a few mirrors of the repository around the place: I dread to think what has happened to them. Are we not causing rather a lot of problems with the only benefit being = that the long term logs are slightly easier to maintain? Surely, if we are = going to use cvs, we really ought to put up with its limitations in favour of = its benefits?=20 I therefore propose that future changes are performed using the 'cvs rm; = cvs add; cvs -m "this file was moved from ???"' approach. The logs are not directly maintained, but they are still available in the 'attic'. The advantages being that a) the move will require no cvs lock-down and b) = the users of vxl will only need to include the '-dP' flags on their regular update (which they should be doing anyway). =20 Geoff. [1] Setting aside the issues with having to 'lock down' the repository = for a number of days. |
From: Ian S. <ian...@st...> - 2003-06-03 09:45:53
|
Whilst I agree that cvs is a pain in this respect, I think that the real cause of the problem is that we are using cvs to distribute latest versions of VXL to users. I (as a maintainer) would prefer to see continuous history files, and instead send emails to users explaining what to do. I must admit that I have been lax in sending out an email to vxl-users explaining how to deal with the repository edits. Ian. > -----Original Message----- > From: Geoffrey Cross [mailto:ge...@vi...] > Sent: Tuesday, June 03, 2003 10:14 AM > To: 'Vxl-maintainers (E-mail)' > Subject: [Vxl-maintainers] CVS repository > > > > Fred Wheeler says: > > It seems that, because the repository was directly > modified, "cvs update" > > is > > not enough to get the latest vil. vil/io/CMakeLists.txt -> > > vil1/io/CMakeLists.txt was at version 1.7 and the latest > > vil2/io/CMakeLists.txt -> vil/io/CMakeLists.txt is also at > version 1.7, so > > my checkout thinks it has the latest version. That's why all the > > dashboards > > have the same incorrect vil/io/CMakeLists.txt, as Peter noted. > > I've had a couple of personal complaints over the last few > days about the > cvs repository fiddling which was necessary in order to do the recent > vil/vil1/vil2 move. > > It is clear that there is a significant hole in the > capabilities of cvs as > it is not possible to move a file whilst maintaining the log > entries. The > method which has recently been adopted, and adopted in a > number of cases in > the past, is to 'hack' around directly within the repository > in order to > perform these changes. Whilst this method does perform the > prerequisite > 'move' it does cause a number of problems for old checkouts > and often the > only sensible solution is to perform a new checkout and start from > scratch[1]. Don't forget that a large number of vxl users > are, indeed, > 'users' and are not cvs experts. Clearly the move has caused > havoc with the > dashboard. And (whilst I know it is not recommended) I > believe there are > still a few mirrors of the repository around the place: I > dread to think > what has happened to them. > > Are we not causing rather a lot of problems with the only > benefit being that > the long term logs are slightly easier to maintain? Surely, > if we are going > to use cvs, we really ought to put up with its limitations in > favour of its > benefits? > > I therefore propose that future changes are performed using > the 'cvs rm; cvs > add; cvs -m "this file was moved from ???"' approach. The > logs are not > directly maintained, but they are still available in the 'attic'. The > advantages being that a) the move will require no cvs > lock-down and b) the > users of vxl will only need to include the '-dP' flags on > their regular > update (which they should be doing anyway). > > > Geoff. > > [1] Setting aside the issues with having to 'lock down' the > repository for a > number of days. > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Geoffrey C. <ge...@vi...> - 2003-06-03 10:06:53
|
> Whilst I agree that cvs is a pain in this respect, I think that the = real > cause of the problem is that we are using cvs to distribute latest > versions > of VXL to users. Not rare these days: most projects I look at offer development code = under cvs and I've never seen any of them send out messages regarding cvs repository changes. =20 Further, if we could guarantee that releases would be regular and = frequent (monthly, I would imagine) it might be ok to discourage users from = taking cvs code. > I (as a maintainer) would prefer to see continuous history files,=20 I agree that I would 'prefer' to see continuous history files, but is it really _necessary_, given the other issues? (if it were necessary, we = might even be able to write a script which would collate logs by following a = file as it is moved). > and > instead send emails to users explaining what to do.=20 This seems like something which should be in big bold red at the top of = a web-page. I'd say it's pretty important as far as vxl being a 'service = to the community' goes. Emails get lost, get discarded, don't get read, = and this also assumes that everyone is a member of vxl-users. Geoff. |
From: Philip P. <p.p...@2d...> - 2003-06-03 11:18:19
|
As someone developing commercial software using vxl, I'd have to say that it is very painful when you start hacking the repository in order to affect name changes to libraries. I decided a while ago that the best way of using vxl was to occasionally tag (and sometimes branch) the vxl repository so that I could recover older versions of vxl that older versions of our products linked against. Clearly this is unworkable when the repository is being hacked so its back to tarballs. As Geoff says, I have never come across another project using CVS where the repository is hacked simply to make directory structure and naming more aesthetically pleasing . Cheers, Phil On Tuesday, June 3, 2003, at 11:06 AM, Geoffrey Cross wrote: > > >> Whilst I agree that cvs is a pain in this respect, I think that the >> real >> cause of the problem is that we are using cvs to distribute latest >> versions >> of VXL to users. > > Not rare these days: most projects I look at offer development code > under > cvs and I've never seen any of them send out messages regarding cvs > repository changes. > > Further, if we could guarantee that releases would be regular and > frequent > (monthly, I would imagine) it might be ok to discourage users from > taking > cvs code. > >> I (as a maintainer) would prefer to see continuous history files, > > I agree that I would 'prefer' to see continuous history files, but is > it > really _necessary_, given the other issues? (if it were necessary, we > might > even be able to write a script which would collate logs by following a > file > as it is moved). > >> and >> instead send emails to users explaining what to do. > > This seems like something which should be in big bold red at the top > of a > web-page. I'd say it's pretty important as far as vxl being a > 'service to > the community' goes. Emails get lost, get discarded, don't get read, > and > this also assumes that everyone is a member of vxl-users. > > Geoff. > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: William A. H. <bil...@ny...> - 2003-06-03 13:24:24
|
I agree, CVS repositories should never be moved around. To move directories and keep old tags, we do the following: 1. copy the ,v files to the new directory 2. cvs remove all the files from the old directory The directory will stay around unless you do a cvs update -P (prune). However, all the old tags will still work, and you still have cvs history on the old files. Of course you could just cvs add the files instead of coping the ,v files, but you lose the history for the files in that directory, but the history is still in the removed directory if you need it. -Bill At 07:17 AM 6/3/2003, Philip Pritchett wrote: >As someone developing commercial software using vxl, I'd have to say that it is very painful when you start hacking the repository in order to affect name changes to libraries. I decided a while ago that the best way of using vxl was to occasionally tag (and sometimes branch) the vxl repository so that I could recover older versions of vxl that older versions of our products linked against. Clearly this is unworkable when the repository is being hacked so its back to tarballs. >As Geoff says, I have never come across another project using CVS where the repository is hacked simply to make directory structure and naming more aesthetically pleasing . > >Cheers, >Phil > > > >On Tuesday, June 3, 2003, at 11:06 AM, Geoffrey Cross wrote: > >> >> >>>Whilst I agree that cvs is a pain in this respect, I think that the real >>>cause of the problem is that we are using cvs to distribute latest >>>versions >>>of VXL to users. >> >>Not rare these days: most projects I look at offer development code under >>cvs and I've never seen any of them send out messages regarding cvs >>repository changes. >> >>Further, if we could guarantee that releases would be regular and frequent >>(monthly, I would imagine) it might be ok to discourage users from taking >>cvs code. >> >>>I (as a maintainer) would prefer to see continuous history files, >> >>I agree that I would 'prefer' to see continuous history files, but is it >>really _necessary_, given the other issues? (if it were necessary, we might >>even be able to write a script which would collate logs by following a file >>as it is moved). >> >>>and >>>instead send emails to users explaining what to do. >> >>This seems like something which should be in big bold red at the top of a >>web-page. I'd say it's pretty important as far as vxl being a 'service to >>the community' goes. Emails get lost, get discarded, don't get read, and >>this also assumes that everyone is a member of vxl-users. >> >>Geoff. >> >> >> >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: eBay >>Get office equipment for less on eBay! >>http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 >>_______________________________________________ >>Vxl-maintainers mailing list >>Vxl...@li... >>https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > >------------------------------------------------------- >This SF.net email is sponsored by: eBay >Get office equipment for less on eBay! >http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Ian S. <ian...@st...> - 2003-06-03 14:24:27
|
I think Bill's solution is best for any further such modifications. If you are careful not to have two different files with the same name before and after the change, then everybody is happy. No annoyed users and full history information. Ian. > -----Original Message----- > From: William A. Hoffman [mailto:bil...@ny...] > Sent: Tuesday, June 03, 2003 2:24 PM > To: Philip Pritchett; Geoffrey Cross > Cc: 'Vxl-maintainers (E-mail)' > Subject: Re: [Vxl-maintainers] CVS repository > > > I agree, CVS repositories should never be moved around. > To move directories and keep old tags, we do the following: > > 1. copy the ,v files to the new directory > 2. cvs remove all the files from the old directory > > > The directory will stay around unless you do a cvs update -P (prune). > However, all the old tags will still work, and you still have cvs > history on the old files. Of course you could just cvs add > the files instead of coping the ,v files, but you lose the history for > the files in that directory, but the history is still in the removed > directory if you need it. > > -Bill > > > At 07:17 AM 6/3/2003, Philip Pritchett wrote: > >As someone developing commercial software using vxl, I'd > have to say that it is very painful when you start hacking > the repository in order to affect name changes to libraries. > I decided a while ago that the best way of using vxl was to > occasionally tag (and sometimes branch) the vxl repository so > that I could recover older versions of vxl that older > versions of our products linked against. Clearly this is > unworkable when the repository is being hacked so its back to > tarballs. > >As Geoff says, I have never come across another project > using CVS where the repository is hacked simply to make > directory structure and naming more aesthetically pleasing . > > > >Cheers, > >Phil > > > > > > > >On Tuesday, June 3, 2003, at 11:06 AM, Geoffrey Cross wrote: > > > >> > >> > >>>Whilst I agree that cvs is a pain in this respect, I think > that the real > >>>cause of the problem is that we are using cvs to distribute latest > >>>versions > >>>of VXL to users. > >> > >>Not rare these days: most projects I look at offer > development code under > >>cvs and I've never seen any of them send out messages regarding cvs > >>repository changes. > >> > >>Further, if we could guarantee that releases would be > regular and frequent > >>(monthly, I would imagine) it might be ok to discourage > users from taking > >>cvs code. > >> > >>>I (as a maintainer) would prefer to see continuous history files, > >> > >>I agree that I would 'prefer' to see continuous history > files, but is it > >>really _necessary_, given the other issues? (if it were > necessary, we might > >>even be able to write a script which would collate logs by > following a file > >>as it is moved). > >> > >>>and > >>>instead send emails to users explaining what to do. > >> > >>This seems like something which should be in big bold red > at the top of a > >>web-page. I'd say it's pretty important as far as vxl > being a 'service to > >>the community' goes. Emails get lost, get discarded, don't > get read, and > >>this also assumes that everyone is a member of vxl-users. > >> > >>Geoff. > >> > >> > >> > >> > >> > >> > >>------------------------------------------------------- > >>This SF.net email is sponsored by: eBay > >>Get office equipment for less on eBay! > >>http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > >>_______________________________________________ > >>Vxl-maintainers mailing list > >>Vxl...@li... > >>https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: eBay > >Get office equipment for less on eBay! > >http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > >_______________________________________________ > >Vxl-maintainers mailing list > >Vxl...@li... > >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Geoffrey C. <ge...@vi...> - 2003-06-03 14:33:19
|
> I think Bill's solution is best for any further such modifications. > > If you are careful not to have two different files with the same name > before > and after the change, then everybody is happy. No annoyed users and full > history information. I like Bill's solution, although I'm still concerned that it involves another lock-down (which was what actually caused on of the complaints I received). Until sourceforge allow this to be done interactively, I don't think we should have another lock-down. Geoff. |
From: Ian S. <ian...@st...> - 2003-06-03 14:58:04
|
> -----Original Message----- > From: Geoffrey Cross [mailto:ge...@vi...] > > > I think Bill's solution is best for any further such modifications. > > > > If you are careful not to have two different files with the > same name > > before > > and after the change, then everybody is happy. No annoyed > users and full > > history information. > > I like Bill's solution, although I'm still concerned that it involves > another lock-down (which was what actually caused on of the > complaints I > received). The lockdown was for commits only - which I don't think affects your users. The fact that nobody could download for a few days was due to a separate problem at SF which could not have been foreseen, and which is unlikely to happen again. > Until SourceForge allow this to be done > interactively, I don't > think we should have another lock-down. > There is a half-way house which solves this problem now, and which we have used in the past. We can submit a script or list of commands that SF support will execute on our behalf on the repository. They only need to put a short term lock on the repository - which is indistinguishable from one of CVS's own write locks. It requires careful testing of the script on a copy of the repository before hand, but for suitable cases it isn't much extra work for the developer managing the changes. The mods due to the vil renaming were too numerous and complex to use this approach, but it should be suitable for the proposed vidl renaming. Ian. |
From: Ian S. <ian...@st...> - 2003-06-03 13:37:35
|
What should Joe do about his proposed changes to vidl to use the new vil? Will further repository surgery annoy users even more, or have we already reach saturation? Should he just do it using cvs operations? I still maintain that CVS is there for the benefit of developers, not users, but since I am neither a developer or user of vidl I don't really mind how the changes take place. > -----Original Message----- > From: Philip Pritchett [mailto:p.p...@2d...] > ... > As someone developing commercial software using vxl, I'd have to say > that it is very painful when you start hacking the repository > in order > to affect name changes to libraries. I decided a while ago that the > best way of using vxl was to occasionally tag (and sometimes branch) > the vxl repository so that I could recover older versions of vxl that > older versions of our products linked against. Clearly this is > unworkable when the repository is being hacked so its back to > tarballs. I think this is a very reasonable argument, and one I had not considered before. In particular this issue is not resolvable by being careful to have distinct names for different files before and after the conversion, or by splitting such collisions into two separate renames, to give everybody's local CVS a chance to cope. My first reaction is that relying on any external data source for the integrity of a company's product is quite risky. I wouldn't be surprised though, if our spin-offs did exactly the same :-) I guess, in the long term subversion (a compelling replacement for CVS) will solve this problem, even if they do seem to be taking as long as us to get to version 1.0 Ian. |
From: Geoffrey C. <ge...@vi...> - 2003-06-03 14:11:50
|
> What should Joe do about his proposed changes to vidl to use the new = vil? > > Should he just do it using cvs operations? As you would probably guess, my opinion is that this should be done with = cvs commands. The first log entry for the moved files would be "*** moved = from core/vidl ***" or something similar in case someone wants to look for = the old history. Geoff. |
From: Amitha P. <pe...@cs...> - 2003-06-25 14:48:10
|
On Tue 03 Jun 2003, Geoffrey Cross wrote: > As you would probably guess, my opinion is that this should be done with cvs > commands. The first log entry for the moved files would be "*** moved from > core/vidl ***" or something similar in case someone wants to look for the > old history. Jumping in quite late, since I've been on vacation: An option is to use only cvs commands, as Geoff suggested, but make the first log entry an entire copy of the previous log, in addition to "renamed from". This avoids the need to recurse through past names to look at the log information. The advantage of this is that we maintain full log information (but not the ability to diff against old versions). However, this also implies large log files; I'm not sure the trade-off is worth it. A few times, I've wanted the log information and it wasn't readily available. I can't recall now whether this was because of renaming, or because the information simply wasn't available in the repository. (I seem to recall "Oxford sync" being the log message for a substantial number of changes, for example.) Amitha. |