RE: Exp state on top of dead
Hi Mark, Thanks for replying. Given that it is possible to have more than one 'corruption' in a given file, but that not all checks would be performed once some kind of corruption is detected, I am not certain how useful a keycode would really be. Well, I was just thinking that it's just an indication, but I also see your point. If an indication was given then iteratively one might get rid of all the errors. Corruptions: I may come back to this list with questions about these. A possible way to help isolate your corruptions would be to take the list of files that are listed as being corrupt and copy them into a new dummy repository and then rerun the validate_repo script with --verbose on those set of files. This would let you work on fixing those files in isolation. Sure - I'll work something out. Thanks to you and everyone on this list for your help. Many regards, David. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Exp state on top of dead
Hi Mark, Sure. A 'wget' or 'fetch' on the following URL should give you a copy of the latest revision of the script: http://cvs.savannah.nongnu.org/viewcvs/ccvs/contrib/validate_repo.pl?rev=HEA Droot=cvs Enjoy! -- Mark Got it. It's installed and configured to run on a regular basis. Only one slight thing I'd like to change with the script would be to have a little reason keycode by each file at the end of the report as to why the script thinks it's corrupt. We've got approx 700,000 files in our repository and if we ran -v on the whole lot we'd have too much output. Apart from that, it's a really nice script, I wish I'd known about it earlier. Cheers, David. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Exp state on top of dead
Hi Mark, Ahhh.. Right. Well, you are correct that the current valid_repo code did not notice this problem at present... I have committed the patch below to find this and related problems that might exist. Excellent stuff. Unfortunately I can't seem to apply this patch. Solaris patch says I can't seem to find a patch in there anywhere, and Linux says Hunk #1 FAILED at 362 then same for Hunk #2 and 3 and 4. I'm trying against the version that comes with 1.12.13.1 - this is the most recent I could find in: http://ftp.gnu.org/non-gnu/cvs/source/nightly-snapshots/feature/ I also tried quite a few of the options to patch with no luck. Is there a cvsweb view of this somewhere, where I could just copy and paste the entire script? Many thanks, David. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Exp state on top of dead
Hi Jim, This is not a problem with validate_repo. A dead revision followed by a live revision is a perfectly valid state for a repository file, and in no way (in general) does it indicate a problem. For branch versions, perhaps, but if I had 'dead' at 1.5 and 'Exp' at 1.6 that would be a problem, no? The other people on this list seemed to think so a while ago. Thanks, David. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Exp state on top of dead
Hi Larry, For branch versions, perhaps, but if I had 'dead' at 1.5 and 'Exp' at 1.6 that would be a problem, no? No. That just means that the file was removed, but then later added back again (or a completely new file was added that just happened to have the same name). The problem is a live file in the Attic (or a dead file that's not in the Attic). Yes, I should have been more clear. My script is examining only the files in the Attics. I'll test for dead files not in the Attics in another pass. Cheers, David. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Exp state on top of dead
Use rlog rather than log. Legend. Thank you. Cheers, David. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Exp state on top of dead
Hi Mark, I believe you are talking about the fact that someone managed to have a live revision (where the someone = me. state was NOT 'dead') in the Attic of its directory. That is/was an observed bug in that a checkout of the main trunk would not find that particular file correctly. Sorry, didn't make myself 100% clear. Thanks, David. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Exp state on top of dead
Hi Larry Et. Al., From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 24 August 2006 18:20 To: CARTER-HITCHIN, David, GBM Cc: [EMAIL PROTECTED]; info-cvs@nongnu.org Subject: Re: Exp state on top of dead CARTER-HITCHIN, David, GBM writes: So the fix would be to manually resurrect it (by simply moving it out of the Attic?) then re-running the cvs remove command, so that it goes back into the Attic and gets status dead on the HEAD revision? If you just want to really kill it, there's no need to move it -- just get a working copy (either check out that specific file or do an update with that file name in an existing working directory) then cvs remove and commit it. In this particular instance we wanted to kill it, so thanks for your suggestions. I checked out the specific version, removed the sticky version tag, rm'ed it and cvs removed it, and commited. It now shows 'dead' on head revision. Let's hope it stays that way. What worries me now is the possibility of there more files lurking out there which are in the same state so I'm trying to write a little script to identify them.Note that validate_repo did *not* flag this as a problem, even with -a switched on. If run with -v, I can see 'dead' whizz by well before 'Exp' later at HEAD, so it has the opportunity to catch this (author cc'd in case [s]he's interested/has time to build this check in). I thought about modifying validate_repo, but then thought it might be easier to write my own. The problem I have is that I can't seem to do a 'cvs log' without checking out the code. If this script gets run as the repository owner, on the cvs server machine, then I set the CVSROOT to :local:/path/to/repository and in theory I'm set (?) but 'cvs log module/file' complains that there is no module called 'module' 'here', even if i'm in the repository itself. Obviously I want to avoid checking out the entire codebase to check things. I could use a perl module to parse the raw RCS file, or write my own, but I'd prefer to rely on native CVS commands. Is there a way to achieve this? Many thanks, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Exp state on top of dead
Hi, We've got a file which is 'dead' at revision 1.11 but 'Exp' at 1.12 and 1.13. The file is now in the Attic in the repository. If I checkout HEAD, I don't get this file, so it's 'dead' for all intents and purposes. However, one of our chaps somehow checked this file out (working with HEAD), so I suppose the solution for him is to simply remove it from his 'CVS/Entries' and remove his copy of it. Begs the question though, how did 1.12 and 1.13 get there? Is it a problem? If so what's the solution? Thanks, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Exp state on top of dead
Dear Mark, Larry, Thank you both for your detailed responses. We are currently using 1.12.9 and have been for the last couple of years. Before then it was 1.11.x IIRC. The last Exp status dates back to 1998 then and who knows what they were using at that time (our project is a lot older than that too :-). We do use NFS, but we've got it hard mounted with no interrupt, so it should be safe. I think the explanation below is more believable than any disk issues. I'm running the contrib/validate_repo script now (thanks for mentioning it - I never realised it was there) to see what else that my throw up. This sounds like a bug. The Attic directory is intended as an optimization for the main trunk. A file with live versions on the main trunk should not be in the Attic directory and should have been resurrected when 1.12 was added. I seem to remember fixing a bug a good while ago where some combination of circumstances would cause CVS to forget to move a resurrected file out of the Attic. So the fix would be to manually resurrect it (by simply moving it out of the Attic?) then re-running the cvs remove command, so that it goes back into the Attic and gets status dead on the HEAD revision? Many thanks, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Branches
Hi Jim, That depends on the nature of the tweak. If the tag represents a live production release, and the promotion is a bugfix, then a new branch is not appropriate imho, as an future releases will come off the main branch, not off this tag. I suppose it depends on the quantity and duration of the bugfixes though :-) That is precisely one case where I would strongly argue the opposite case, in fact. If it is simply a bug fix to an existing release, then the most appropriate course is to branch from the release, and put the bug fix in both the branch and the main development. Don't follow the Microsoft release model, where bug fixes get rolled in with new features (which introduce new bugs, thus perpetuating the cycle). Not sure I understand your reasoning here. If we: - branch off HEAD for major releases - take a tags off the branch for releases then if a bugfix comes along we generally put it into the current branch (and into HEAD, if appropriate, which it generally is) and then promote the bugfix revision which is on the branch to the current production tag and release that. This does not compromise new releases - the bugfix goes to where it belongs. I think your suggestion is to branch again from the tag, but then the bugfix potentially needs to go into three places (HEAD, major branch and your new branch). If we get 3 bugfixes on Monday,Tuesday and Wednesday, we're going to end up with 4 branches by Wednesday afternoon! Perhaps I misunderstand your scheme. ... considered excessive. Also, quoting entire disclaimers and long signatures is almost never necessary. On the topic of which, please speak with the powers-that-be in your organization, and point out to them that automatically appending such disclaimers to each and every outgoing message, especially when the recipient is a list, dilutes the meaning and effectiveness of the email. Sorry, it's out of my control. There are 120,000+ employees here. Even if I could track down the relevant person, it is highly unlikely that I could influence their decision to change it, as it is a legal statement, and IANAL. I could show them the relevant part of http://www.ietf.org/rfc/rfc1855.txt, but I have extremely low expectations that it would actually change anything. Please just snip everything after --, that's what it's there for. Some other lists, like ACCU-general, which if memory serves me right I've seen you on, have the --LongSig mecahnism or something similar to do that for you - perhaps that could be done on this list? Cheers, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Branches
cvs rtag -r OLD VERSION OF FILE -F BRANCH_TAG_NAME module/filename If there is a particular release point that the management wants tweaked, then it is much simpler to branch from that release point. That way, you won't have to back out any changes. That depends on the nature of the tweak. If the tag represents a live production release, and the promotion is a bugfix, then a new branch is not appropriate imho, as an future releases will come off the main branch, not off this tag. I suppose it depends on the quantity and duration of the bugfixes though :-) [Please trim excess quotes in the future] What you and I consider excess could well be different. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Branches
the standard practice is to keep the trunk (cvs special tag HEAD) to be your new code (aka mainline), and the branches for what you're calling 'old code' (aka releases). David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Ray Booysen Sent: 23 June 2006 10:03 To: info-cvs@nongnu.org Subject: Branches Hi all I am hoping for a little clarification around branching. Currently we are not using branching at all in our code. The tree is a straight line without the need for any branches. So here comes the question. I started on a new section of code to rewrite a reporting module that wasn't functioning well. I now am halfway through this. However, management have come and said because of timescales, can I tweak the old reporting module and leave the new code for a later version. Now obviously I don't want to lose the current work I've done. What is the best way to accomplish this? Should I branch the code and have the new code running as a separate branch and tweak the old code on the trunk? Or should the changing of the old code be on the branch and have the new code on the trunk? The other developers on the team would be working on the trunk which is why I'd prefer to have the new code on the branch. Which is the best way to handle this? Kind Regards Ray -- Ray Booysen [EMAIL PROTECTED] ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: Branches
CVS will keep track of revisions, it won't help you write code! branch your code then in the trunk finish your dev mainline work, in the branch back out the new changes that you don't want in that release. You can do this with rtag: cvs rtag -r OLD VERSION OF FILE -F BRANCH_TAG_NAME module/filename When you're ready to do a release of your old code, take a tag off the branch and release from that: cvs rtag -r BRANCH_TAG_NAME TAG_NAME module If you do this for all your releases, with new branches taken for major releases, tags taken off the branch for minor releases, then you will avoid the situation you're in now. Cheers, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 -Original Message- From: Ray Booysen [mailto:[EMAIL PROTECTED] Sent: 23 June 2006 11:40 To: CARTER-HITCHIN, David, GBM Cc: info-cvs@nongnu.org Subject: Re: Branches The problem I have is the new code is half-finished and is required for the rest of the developers to work... HELP! :P CARTER-HITCHIN, David, GBM wrote: the standard practice is to keep the trunk (cvs special tag HEAD) to be your new code (aka mainline), and the branches for what you're calling 'old code' (aka releases). David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Ray Booysen Sent: 23 June 2006 10:03 To: info-cvs@nongnu.org Subject: Branches Hi all I am hoping for a little clarification around branching. Currently we are not using branching at all in our code. The tree is a straight line without the need for any branches. So here comes the question. I started on a new section of code to rewrite a reporting module that wasn't functioning well. I now am halfway through this. However, management have come and said because of timescales, can I tweak the old reporting module and leave the new code for a later version. Now obviously I don't want to lose the current work I've done. What is the best way to accomplish this? Should I branch the code and have the new code running as a separate branch and tweak the old code on the trunk? Or should the changing of the old code be on the branch and have the new code on the trunk? The other developers on the team would be working on the trunk which is why I'd prefer to have the new code on the branch. Which is the best way to handle this? Kind Regards Ray -- Ray Booysen [EMAIL PROTECTED] ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs ** * The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com ** * From - Fri -- Ray Booysen [EMAIL PROTECTED] ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: software for statistics of cvs
Title: Message we use StatCVS: http://statcvs.sourceforge.net/ Cheers, David Carter-Hitchin.-- -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ankush groverSent: Sunday, 28 May 2006 6:44 PMTo: info-cvs@gnu.orgSubject: software for statistics of cvshey friends,I am using cvs on fc3 and I need a software which can show details like per user statistics, number of files added . The software should support multiple repositories automatic statistics like refreshing details every 15 minutes. There is a software called CVSManager but the free edition only supports 2 repositories and I am looking for a that should support multiple repositories and should be free. Is there any such software other than CVSManager ?Thanks RegardsAnkush Grover *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: backing up of cvs repositories
Hi, --exclude '#cvs.lock' \ --exclude '#cvs.history.lock' \ --exlcude '#cvs.val-tags.lock' \ --exlcude '#cvs.rfl*' \ --exlcude '#cvs.pfl*' \ --exlcude '#cvs.wfl*' \ --exlcude ',*,' \ --exclude 'CVS' If using rsync, then --cvs-exclude does the magic above. Cheers, David -- *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: old fileattr files - safe to delete?
Hi Arthur, Again thanks for the interest. We're mainly a UNIX/Linux based operation, but there are some windows users out there (poor souls). Cheers, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 -Original Message- From: Arthur Barrett [mailto:[EMAIL PROTECTED] Sent: 27 May 2006 20:38 To: CARTER-HITCHIN, David, GBM; info-cvs@gnu.org Subject: RE: old fileattr files - safe to delete? David, If you are using CVSNT as a client and CVS as a server then they were simply watches. However if you have CVSNT on the server then I suggest you subscribe to the CVSNT list instead: http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt or news://news.cvsnt.org/support.cvsnt If you are using CVS as a server and CVSNT (or TortosieCVS/WinCVS) extensively as a client then I recommend upgrading the server to CVSNT 2.5.03 (available for free for Linux/Unix/Mac/Windows). CVSNT server generally works best with CVSNT client and has many additional features for commercial software development such as mergepoints (visual tracking of when and where merges occur), change sets ( group and track and merge changes by an arbitrary group), failsafe audit to database (if audit fails then so does the client operation) and a separate contention lock service. Regards, Arthur Barrett -Original Message- From: CARTER-HITCHIN, David, GBM [mailto:[EMAIL PROTECTED] Sent: Sunday, 28 May 2006 12:45 AM To: Arthur Barrett; info-cvs@gnu.org Subject: RE: old fileattr files - safe to delete? Hi Arthur, Thanks for you comments, but too late! They've gone. They were very old and applied to users who've now left. Are you sure these are different at the repository end, if cvsnt is being used? I can see how that could be.. Cheers, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 -Original Message- From: Arthur Barrett [mailto:[EMAIL PROTECTED] Sent: 27 May 2006 04:38 To: CARTER-HITCHIN, David, GBM; info-cvs@gnu.org Subject: RE: old fileattr files - safe to delete? David, I know some people in your company are using CVSNT on Linux/Unix/Windows. In this case you should definitely not touch these fileattr files since they contain the permissions/ACL's. Regards, Arthur Barrett ** ** *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com ** ** *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: old fileattr files - safe to delete?
Hi Arthur, Thanks for you comments, but too late! They've gone. They were very old and applied to users who've now left. Are you sure these are different at the repository end, if cvsnt is being used? I can see how that could be.. Cheers, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 -Original Message- From: Arthur Barrett [mailto:[EMAIL PROTECTED] Sent: 27 May 2006 04:38 To: CARTER-HITCHIN, David, GBM; info-cvs@gnu.org Subject: RE: old fileattr files - safe to delete? David, I know some people in your company are using CVSNT on Linux/Unix/Windows. In this case you should definitely not touch these fileattr files since they contain the permissions/ACL's. Regards, Arthur Barrett *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
RE: old fileattr files - safe to delete?
Stuart, Mark, Many thanks for your help - I've removed the old fileattr files and things look much better. Sorry about my signature - nothing I can do about it - please filter everything after --. Some lists chop off everything after: --LongSig Does that work here? Thanks, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 -Original Message- From: Stuart Cooper [mailto:[EMAIL PROTECTED] Sent: 25 May 2006 00:59 To: CARTER-HITCHIN, David, GBM Cc: info-cvs@gnu.org Subject: Re: old fileattr files - safe to delete? We've got a bunch of CVS/fileattr files in our repository that are ancient. I think I'm right in saying that the only way that these get created are when people run 'cvs watch' and 'cvs edit'. The people who did this have long since gone and so have their logins. Is it safe to just delete the fileattr files to get rid of the watches or is there an official way? You're correct that the only way fileattr files are created in the repository is through cvs watch and cvs edit. CVS removes fileattr and the CVS subdirectory when there are no more watchers or editors for any of the files in that directory. A combination of $ cvs unedit $ cvs watch off $ cvs watch remove should get rid of the fileattrs although since you've lost the old logins this might not be trivial. It should be entirely safe to remove the CVS directories by hand from the repository itself. Good luck, Stuart. *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
Odd behaviour with dead file
Hi, We've got a stange file in our repository that was 'cvs remove'd, i.e. state 'dead' at revision 1.4 but somehow we've got version 1.5, 1.6, 1.7 and 1.8 all in state 'Exp'. Is there something that can explain this behaviour? In the reposity the ,v file is in the Attic directory. This file is also strange in that on some sandboxes it appears (and will not go away, even if we delete and checkout the directory again) and yet if we checkout the whole module, then the file isn't there. One of the sandboxes is on a Windows machine (most of out machines are Linux and Solaris) and this machine has CVS/Entries.Extra files which I've never see before - perhaps this is part of the problem? If I do a fresh checkout of the whole module, then cd into the directory where the file was and do a 'cvs status' I see: File: no file xxx_xxx_xxx.cpp Status: Needs Checkout Working revision:No entry for xxx_xxx_xxx.cpp Repository revision: 1.8 /path/to/cvs/dir/dir/Attic/xxx_xxx_xxx.cpp Can anyone an insight into what is happening here? Perhaps this is normal and I'm missing something obvious... Many thanks, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
old fileattr files - safe to delete?
Hi, We've got a bunch of CVS/fileattr files in our repository that are ancient. I think I'm right in saying that the only way that these get created are when people run 'cvs watch' and 'cvs edit'. The people who did this have long since gone and so have their logins. Is it safe to just delete the fileattr files to get rid of the watches or is there an official way? Thanks, David Carter-Hitchin. -- Royal Bank of Scotland Interest Rate Derivatives IT 135 Bishopsgate LONDON EC2M 3TP Tel: +44 (0) 207 085 1088 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorized and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbos.com http://www.rbsmarkets.com *** ___ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs
