Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg A. Woods [EMAIL PROTECTED] writes: There is no trigger for cvs rm and there MUST _NOT_ be. There is no trigger for cvs add and there MUST _NOT_ be. Please defend your position for 'MUST NOT' as it seems an entirely reasonable suggestion that additional triggers might wish to be imposed by a repository administrator. Today, there is no direct trigger for 'cvs rm'. I do not have strong feelings about adding one because existing clients do not yet talk to the server for this operation which only becomes visible when the user does a commit and a user could always work around the prohibition of doing a 'cvs rm' by truncating the file to zero length and committing that which will not matter most of the time. Today, there is no direct trigger for 'cvs add', however, a 'cvs add' of a directory at present is not possible to stop and there are some administrators who would like to impose standards on directory names in the repository. For example, some folks would like to impose the 'no spaces allowed in directory names' to make it possible to add modules entries for all possible directories. This same rational is also true for 'cvs import' which allows users to specify lots of directories and files that only the loginfo script sees after the fact with no checking to see if the vendor tag, version tag or directory names or file names match those allowed by the policy of the administrator. More than one user has requested a trigger for 'cvs import' that gets called before everything just gets dumped into the loginfo trigger. Others have suggested that a series of commitinfo and taginfo may be suitable as an alternative to an importinfo trigger. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBnO3s3x41pRYZE/gRAhdJAKCCBNbUqYkAbG3Wb7UpXLEVVUfMHgCdHHU6 szKXthS/vS5XcP/ExzKlXFc= =U1Cb -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
[ On Thursday, November 18, 2004 at 10:38:44 (-0500), Derek Robert Price wrote: ] Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes) Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can be placed in the user's .cvsrc for the add command and the add will not be allowed unless the server contact and verification is successful. Which of course is an extremely stupid way to implement something that is done for the sole and lone reason of policy enfocement. ;-) It would be saner and safer and much Much MUCH simpler to just write a wrapper script for the CVS client and require (through external security measures, such as peer pressure and/or threat of dismisal) that everyone always use the wrapper script. Remember the very strongest bit of advice for using CVS is to update and to commit early and often (but of course only commit after compiling _everything_ one last time and doing at least a few tests! :-) (which of course implies that day-to-day work using CVS should never be done directly on a baseline branch either, assuming the project needs a working baseline at all times :-) Any fears about early policy enforcement not being possible at cvs add time are ungrounded and illogical in the context of how CVS is used in general. Also the fear about lack of a cvs add hook is pure F.U.D. given that cvs rm also lacks a similar hook (and it lacks it for the same reaons). CVS add and rm commands are intended solely to change the state of the working directory. They MUST NOT require access to the repo or the repo server. They are no different than vi except that they change metadata describing the state of the working directory instead of changing the content of a file. The fact that cvs add came to create a directory in the repository was a hack that was implemented even before CVS supported the client/server mode of operation; and it is a hack that was made simply to avoid having to fix other implementation deficiencies in the code at that time. Of course we went over all of this in excruciating detail the first time this proposal was made and every time it's been seen since and all because of one stick in the mud. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg A. Woods wrote: There is no trigger for cvs rm and there MUST _NOT_ be. There is no trigger for cvs add and there MUST _NOT_ be. I have to admit, there is a certain logic to drawing the line at triggers for repository changes, not workspace changes. The user should have total control over their workspace and the server shouldn't be able to veto anything except changes to the repository. This still requires that `cvs add' of directories not alter the repository until commit. It also reminds me that allowing `cvs add' and `cvs rm' in a workspace without even write privs to the server has been on my wish list for quite awhile (this enables complete patches to be generated from a public repository by anybody). I'm guessing the proposal Greg is advocating would provide for this. I also still would not object to the a `cvs add -C' convenience hook which requested that the client contact the server and validate the add. Any team that valued this option significantly should find it fairly easy to enforce a policy of placing `add -C' in users' .cvsrc files. Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBnPCfLD1OTBfyMaQRAqsWAJ4hbqIedBH7fhcBXeNnErm/PXEsNQCfUgKo Wv/HTA9wD1ZjrLPc4CMjB2k= =GKMh -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg A. Woods wrote: [ On Thursday, November 18, 2004 at 10:38:44 (-0500), Derek Robert Price wrote: ] Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes) Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can be placed in the user's .cvsrc for the add command and the add will not be allowed unless the server contact and verification is successful. Which of course is an extremely stupid way to implement something that is done for the sole and lone reason of policy enfocement. ;-) Only if you view the policy enforcement as policing. If you view it as a development tool, it makes perfect sense. I know that if Paul is correct and his team can really generate days worth of work by adding a file/directory with the wrong name and I were on his team, I would be grateful for an automated check that I was doing the right thing as I went along. It would be saner and safer and much Much MUCH simpler to just write a wrapper script for the CVS client and require (through external security measures, such as peer pressure and/or threat of dismisal) that everyone always use the wrapper script. Maybe, but CVS already has the code to turn the file list, user information, repository path, etc. into simple, script-digestible chunks. A wrapper script might have to duplicate those chunks of code and possibly stay in sync with CVS as CVS metadata file details changed. A hook would be simpler in this regard and I know for a fact that the current overhead of installing another hook in the feature version of CVS is actually rather small. As long as the check could be avoided when necessary or desirable to allow disconnected operation of `cvs add', I don't see why a well-written and complete patch for this should be rejected. Remember the very strongest bit of advice for using CVS is to update and to commit early and often This is true. CVS add and rm commands are intended solely to change the state of the working directory. They MUST NOT require access to the repo or the repo server. They are no different than vi except that they change metadata describing the state of the working directory instead of changing the content of a file. I still back you on this, but also still have absolutely no problem with an optional check. The fact that cvs add came to create a directory in the repository was a hack that was implemented even before CVS supported the client/server mode of operation; and it is a hack that was made simply to avoid having to fix other implementation deficiencies in the code at that time. Of course we went over all of this in excruciating detail the first time this proposal was made and every time it's been seen since and all because of one stick in the mud. Let's see a patch! Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBnPQZLD1OTBfyMaQRApYmAJ49iaP8MU/RrnRm6NmlIW46Je5ESQCeNClV O2J48YBd7tXZmLQWD5WRKng= =hSOJ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-partysources and adding/committing changes)
Me Too post Derek Robert Price wrote: Greg A. Woods wrote: There is no trigger for cvs rm and there MUST _NOT_ be. There is no trigger for cvs add and there MUST _NOT_ be. I have to admit, there is a certain logic to drawing the line at triggers for repository changes, not workspace changes. The user should have total control over their workspace and the server shouldn't be able to veto anything except changes to the repository. I believe this is the crux of the argument, the user should be allowed to do anything they want to in their sandbox, but when they want to change the repository their changes have to conform to any of the requirements of the repository manager has. The transition from sandbox to repository occurs at commit time, so that is when the repository can and should impose it's will. Greg's proposal, the way I read it, would move `cvs add` into conformance with this. SNIP some very nice reasons for Greg's proposal I also still would not object to the a `cvs add -C' convenience hook which requested that the client contact the server and validate the add. Any team that valued this option significantly should find it fairly easy to enforce a policy of placing `add -C' in users' .cvsrc files. I agree that this would be a nice _additional_ patch so the user could validate early on that their information would go in, as it would only require contacting the server in the case of sites where the users know the repository admin has such rules in place, and commit would allow the ENFORCEMENT of those rules. I suspect that a determined user could fake enough information into the CVS/* files to get around the add, but it should be much more difficult to get around commitinfo because all files at that point are under the cvs server's control. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Greg, Is it reasonable to suggest that a addinfo trigger could be run as a part of the 'cvs commit' command should the client not happen to connect to the server for a 'cvs add' operation? The idea would be that having simpler triggers for various kinds of policy makes the administration of a repository easier. In a similar manner a trigger for 'cvs rm' could be implemented to impose policy. The timing of WHEN those triggers get invoked is what seems to be the sticking point for folks... Like Derek, I would not mind a hack to allow a the users to perform a check that all is well... perhaps a 'cvs -n commit' should run those validation checks? I have no objections and would in fact LIKE to see disconnected operations for 'cvs add' if possible. I also suspect that changes to the 'cvs import' mechanism would aslo be useful. For that matter, I would like to see disconnected 'cvs diff' commands where possible for users that already have a CVS/Base/* version of the file around... -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBnPcXDsmuPPFOO2cRAnR1AJ9Vha96Z8s/KN2EIONy3nfZlLlxnQCfVXh2 z7ADxJYod501tENFm8PtN7k= =ksnC -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-partysources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Todd Denniston wrote: I also still would not object to the a `cvs add -C' convenience hook which requested that the client contact the server and validate the add. Any team that valued this option significantly should find it fairly easy to enforce a policy of placing `add -C' in users' .cvsrc files. I agree that this would be a nice _additional_ patch so the user could Absolutely. I intended this as a suggestion for a potential additional patch which I would find acceptable if submitted. I in no way meant to imply that it be a condition for acceptance of any patch generated as a result of Greg's proposal. validate early on that their information would go in, as it would only require contacting the server in the case of sites where the users know the repository admin has such rules in place, and commit would allow the ENFORCEMENT of those rules. I suspect that a determined user could fake enough information into the CVS/* files to get around the add, but it should be much more difficult to get around commitinfo because all files at that point are under the cvs server's control. Exactly. Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBnPhzLD1OTBfyMaQRAki7AJ9YaLWKRJ27ut92CRB3SbJ8RLDvBACeNViR 4AX2p3ruMlYSBKDf0uW3Cgk= =l83S -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: Hi Greg, Is it reasonable to suggest that a addinfo trigger could be run as a part of the 'cvs commit' command should the client not happen to connect to the server for a 'cvs add' operation? It should probably run regardless since it would be much simpler than securely tracking whether the add on the client side had contacted the server. The idea would be that having simpler triggers for various kinds of policy makes the administration of a repository easier. In a similar manner a trigger for 'cvs rm' could be implemented to impose policy. Sure, but again, not by default. The timing of WHEN those triggers get invoked is what seems to be the sticking point for folks... Like Derek, I would not mind a hack to allow a the users to perform a check that all is well... perhaps a 'cvs -n commit' should run those validation checks? That's a good point (and I believe that `cvs -n ci' will aready run any validation checks in place on the commitinfo hook), but allowing them to run from `cvs add -C' might be slightly more convenient and I still argue should be a simple enough addition after Greg's change. I have no objections and would in fact LIKE to see disconnected operations for 'cvs add' if possible. I also suspect that changes to the 'cvs import' mechanism would aslo be useful. Yep. For that matter, I would like to see disconnected 'cvs diff' commands where possible for users that already have a CVS/Base/* version of the file around... Yep. I'm actually tempted to have the CVS client always create the CVS/Base files for just this reason. I think that `cvs diff' against the base revisions is by far the common case but I hadn't completely convinced myself that it was worth the overhead of the duplicate files yet. It would have the secondary side effect of allowing `cvs unedit' in disconnected mode even when files had not been `cvs edit'ed and should be another fairly simple change. :) Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBnPrgLD1OTBfyMaQRAiUkAJ0Rr6JrhZgssbhGzfHU9YNRq6Ca0gCg0f/W Jx3gFST6+PiJNmU6SkiN3nM= =8yfS -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Robert Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Hi Greg, Is it reasonable to suggest that a addinfo trigger could be run as a part of the 'cvs commit' command should the client not happen to connect to the server for a 'cvs add' operation? It should probably run regardless since it would be much simpler than securely tracking whether the add on the client side had contacted the server. Good point. The idea would be that having simpler triggers for various kinds of policy makes the administration of a repository easier. In a similar manner a trigger for 'cvs rm' could be implemented to impose policy. Sure, but again, not by default. Sure. The timing of WHEN those triggers get invoked is what seems to be the sticking point for folks... Like Derek, I would not mind a hack to allow a the users to perform a check that all is well... perhaps a 'cvs -n commit' should run those validation checks? That's a good point (and I believe that `cvs -n ci' will aready run any validation checks in place on the commitinfo hook), but allowing them to run from `cvs add -C' might be slightly more convenient and I still argue should be a simple enough addition after Greg's change. Given we do not currently have those hooks, I have no objections to considering a patch that does this. I have no objections and would in fact LIKE to see disconnected operations for 'cvs add' if possible. I also suspect that changes to the 'cvs import' mechanism would aslo be useful. Yep. For that matter, I would like to see disconnected 'cvs diff' commands where possible for users that already have a CVS/Base/* version of the file around... Yep. I'm actually tempted to have the CVS client always create the CVS/Base files for just this reason. I think that `cvs diff' against the base revisions is by far the common case but I hadn't completely convinced myself that it was worth the overhead of the duplicate files yet. It would have the secondary side effect of allowing `cvs unedit' in disconnected mode even when files had not been `cvs edit'ed and should be another fairly simple change. :) I recommend this be an option that could be requested by the user or the default behavior switched by the CVSROOT/config file. I know of some projects where there will be insufficient room to hold multiple copies of the tree on disk at the same time and it might be desirable to allow the administrator to default the behavior desired with the user able to do an override. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBnPxcDsmuPPFOO2cRAvJ2AJwOpue91rw6uy0hMptvRjr0LIEzWQCeJtO8 qHi+1RzAcYqI0gQTISJ1dBU= =2dsA -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark D. Baushke wrote: For that matter, I would like to see disconnected 'cvs diff' commands where possible for users that already have a CVS/Base/* version of the file around... Yep. I'm actually tempted to have the CVS client always create the CVS/Base files for just this reason. I think that `cvs diff' against the base revisions is by far the common case but I hadn't completely convinced myself that it was worth the overhead of the duplicate files yet. It would have the secondary side effect of allowing `cvs unedit' in disconnected mode even when files had not been `cvs edit'ed and should be another fairly simple change. :) I recommend this be an option that could be requested by the user or the default behavior switched by the CVSROOT/config file. I know of some projects where there will be insufficient room to hold multiple copies of the tree on disk at the same time and it might be desirable to allow the administrator to default the behavior desired with the user able to do an override. Sure. Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBnP5nLD1OTBfyMaQRAjNVAJ9dj1tGB3e0aO9e9gVHwOMYtQskbQCgmU7V Y2C5Vx2Gp1tYwKjIgAFeSLk= =7VuN -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, November 17, 2004 at 09:19:18 (-0800), Paul Sander wrote: ] Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes) It depends on the nature and extent of the changes. I can easily imagine scenarios in which lost productivity would be measured in days, even assuming that all files are ASCII. Your imagination is far too ripe with bizzare paranoia. It's backed by many years of experience. There is no trigger for cvs rm and there MUST _NOT_ be. I wasn't going to mention this, but since you brought it up, removals should also be triggerable events and the same philophy, whatever it is, should be applied to both add-time and remove-time triggers. I have experienced situations where users have removed and committed stuff that had bad effects on the rest of the project. Coworkers have experienced user errors that cleaned out the entire source base of a project, requiring many days to correct. It's situations like this where triggers like this are valuable because they can limit destructive changes to users who know what they're doing. There is no trigger for cvs add and there MUST _NOT_ be. Again here we disagree. Just because you can live without it doesn't mean the rest of the world can. We've already discussed how to add such a capability in such a way that it involves zero overhead for those who don't want it: Register no triggers and defer their enforcement until commit time. But for shops that NEED them, they can register the trigger and turn off deferment. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] [ On Thursday, November 18, 2004 at 10:38:44 (-0500), Derek Robert Price wrote: ] Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes) Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can be placed in the user's .cvsrc for the add command and the add will not be allowed unless the server contact and verification is successful. Which of course is an extremely stupid way to implement something that is done for the sole and lone reason of policy enfocement. ;-) It would be saner and safer and much Much MUCH simpler to just write a wrapper script for the CVS client and require (through external security measures, such as peer pressure and/or threat of dismisal) that everyone always use the wrapper script. It's simpler, but neither safer nor saner to wrapper script around the client. The reason is this: If you enforce policy but give the user an avenue to circumvent it, the user will do so. If you're serious about enforcing policy, then you must have a way to build it into your tools in a way that user cannot defeat. In CVS (and indeed most if not all existing version control systems), that means spawning trigger scripts from within the tool, because wrapper scripts are trivial to defeat. Remember the very strongest bit of advice for using CVS is to update and to commit early and often This is true, but it remains a common belief that nothing should be committed until it's ready for unlimited use by the rest of the project. As long as that paradigm holds, work will continue to be done for long periods of time between commits. Note that this is not what I teach, it's what I see. I would never, ever discourage someone from checking in their work, working or not (though I may recommend doing so on a private branch). But despite my teachings to the user community of the folly of their ways, this we will commit no line until its time mindset persists. (but of course only commit after compiling _everything_ one last time and doing at least a few tests! :-) (which of course implies that day-to-day work using CVS should never be done directly on a baseline branch either, assuming the project needs a working baseline at all times :-) Any fears about early policy enforcement not being possible at cvs add time are ungrounded and illogical in the context of how CVS is used in general. Also the fear about lack of a cvs add hook is pure F.U.D. given that cvs rm also lacks a similar hook (and it lacks it for the same reaons). Claiming that the hooks are not needed in the context of current use is meaningless because the hooks do not currently exist. Such arguments can only be made if one can demonstrate that existing hooks are not used in a meaningful way. On the other hand, we have stated requirements where existing users find existing capability to be inadequate. This is compelling reason to add the requested feature. CVS add and rm commands are intended solely to change the state of the working directory. They MUST NOT require access to the repo or the repo server. They are no different than vi except that they change metadata describing the state of the working directory instead of changing the content of a file. I define the add and rm commands as the actions required to make CVS aware of new artifacts or to remove them from existing configurations. How it does that is to me an implementation detail, and I don't care whether or not the tool considers it necessary to contact the server. However, in the event that triggers are added to track these events, they must be added in such a way that user's can't defeat them by applying more primitive operators or munging their environment. To me, that means building triggers into the server and making the client contact the server at appropriate times to fire the triggers. If there's a better way to do it, I'm open to hearing it. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander [EMAIL PROTECTED] writes: We've already discussed how to add such a capability in such a way that it involves zero overhead for those who don't want it: Register no triggers and defer their enforcement until commit time. But for shops that NEED them, they can register the trigger and turn off deferment. Actually, your arguments in favor of deferment vs non-deferment are not as compelling as the idea that 'cvs add' and 'cvs rm' should be local to the tree until such time as a real 'cvs commit' event occurs. Allowing the user to do checks ahead of time or defaulting that behavior is a fine-detail that could be negotiated, but really any user has control over their own environment, so the best you can provide is advisory checks prior to commit time... -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBnUaD3x41pRYZE/gRAt1oAJ9SjyGJ2BZr+k7+g/5+vhaLVkKZYQCg3mwA ae5mEw72wwi/BkkJWzZcmC8= =8CqN -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] Greg A. Woods wrote: There is no trigger for cvs rm and there MUST _NOT_ be. There is no trigger for cvs add and there MUST _NOT_ be. I have to admit, there is a certain logic to drawing the line at triggers for repository changes, not workspace changes. The user should have total control over their workspace and the server shouldn't be able to veto anything except changes to the repository. There is a certain logic to having triggers gate changes to the repository. There's also a certain logic to having a tool prevent conditions that will later cause it to fail. Uncommitable changes are such a condition, and it simply makes no sense to allow adds to succeed when we know that committing those adds will fail. There's another point I'll make but won't argue over: There's a limit to the amount of control a user should have, even over his own workspace. The user shouldn't be able to corrupt his metadata to the extent that it causes failures, for example. This still requires that `cvs add' of directories not alter the repository until commit. It also reminds me that allowing `cvs add' and `cvs rm' in a workspace without even write privs to the server has been on my wish list for quite awhile (this enables complete patches to be generated from a public repository by anybody). I'm guessing the proposal Greg is advocating would provide for this. Why is having CVS aware of source files an enabler for producing patches? I also still would not object to the a `cvs add -C' convenience hook which requested that the client contact the server and validate the add. Any team that valued this option significantly should find it fairly easy to enforce a policy of placing `add -C' in users' .cvsrc files. I don't consider triggers to be conveniences. If they are to enforce policy then they can't be defeated by the user. This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS. However, if applied to the add command, it is more agreeable than the -C option as described above for human engineering reasons. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] Derek Robert Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Hi Greg, Is it reasonable to suggest that a addinfo trigger could be run as a part of the 'cvs commit' command should the client not happen to connect to the server for a 'cvs add' operation? It should probably run regardless since it would be much simpler than securely tracking whether the add on the client side had contacted the server. Good point. Yes! The idea would be that having simpler triggers for various kinds of policy makes the administration of a repository easier. In a similar manner a trigger for 'cvs rm' could be implemented to impose policy. Sure, but again, not by default. Sure. I think that it should be enabled by default, and the user can put the -n option in his .cvsrc file for the affected commands, both for add and remove. The reasons for this: - It maintains compatibility with existing commands. - The user is caught just once when the trigger fires. Recovery is to interrupt the client, edit .cvsrc, and re-run. In the converse, the user must ask for policy enforcement, and may never get around to it in violation of the project's policy. Unfortunately, there appears to be no way to countermand a -n option, so the only way to turn it off is to edit the .cvsrc file. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: Keep in mind that, although Greg does not acknowledge it, a number of people in this forum have stated a requirement for an add-time trigger that could be used for such things as enforcement of naming conventions and access control. Such a feature (referred to in the past as addinfo) would reinstate the need to contact the server during additions. I would personally be loathe to make any feature that doesn't require a connection require one if it could be helped. In fact, I've actually been thinking about disconnecting some of the other functionality, such as cvs diff against the base version of a file. Perhaps if the connection failed and then the work was simply done locally, it would be acceptable. Why is an add hook considered to be an improvement over the hook that runs at commit time? Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBm5+lLD1OTBfyMaQRAqmxAJ0U0EdgEPsRBuPgxeeW/OOwROQNfgCcDF8U 1w269ZRE/S0FrIIinzTCgxw= =9brE -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: Keep in mind that, although Greg does not acknowledge it, a number of people in this forum have stated a requirement for an add-time trigger that could be used for such things as enforcement of naming conventions and access control. Such a feature (referred to in the past as addinfo) would reinstate the need to contact the server during additions. I would personally be loathe to make any feature that doesn't require a connection require one if it could be helped. In fact, I've actually been thinking about disconnecting some of the other functionality, such as cvs diff against the base version of a file. Perhaps if the connection failed and then the work was simply done locally, it would be acceptable. It's fair to say that the client shouldn't gratuitously contact the server. On the other hand, I think it's safe to say that several of us in this forum disagree over what is gratuitous. I happen to think that triggers should run on the server, and therefore any triggerable event should contact the server. Why is an add hook considered to be an improvement over the hook that runs at commit time? It's true that add and commit hooks can enforce the same kinds of policies as post-conditions of the commit. However, add hooks can enforce things like naming conventions. I'm working in a shop right now that prefers to have additions to the source tree (particularly new directories) be made by the architects of the project rather than the rank and file, and such a policy is best enforced at add time. The reason why I say these are best done at add time is because if the add succeeds then the user is likely to do a lot more work under the assumption that the subsequent commit will succeed (or at least not fail due to conditions created by the add). If the commit fails due to an improper add, then the user must re-do (or un-do) a bunch of work. All those hours of lost productivity could have been avoided by an add-time hook. The counter-argument is that CVS is not a project management tool, and that if the conditions I describe above come to be then it must a problem in that area. But keep in mind that hooks exist to enforce policies set by project management. If you want to blame violations of policy on bad management, then you might as well remove all hooks. If you want mechanized policy enforcement using hooks, then do it right, in all the places where it's needed. And I contend that add time is one place where it's needed. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: It's true that add and commit hooks can enforce the same kinds of policies as post-conditions of the commit. However, add hooks can enforce things like naming conventions. I'm working in a shop right now that prefers to have additions to the source tree (particularly new directories) be made by the architects of the project rather than the rank and file, and such a policy is best enforced at add time. The reason why I say these are best done at add time is because if the add succeeds then the user is likely to do a lot more work under the assumption that the subsequent commit will succeed (or at least not fail due to conditions created by the add). If the commit fails due to an improper add, then the user must re-do (or un-do) a bunch of work. All those hours of lost productivity could have been avoided by an add-time hook. This might be true, but it seems to me that most damage due to your lost productivity could be fixed with a rename or two and maybe a few `sed' runs, in a few minutes. At least in an environment where most of the files concerned were text files, as will usually be the case using CVS. It might be interesting to see Greg's patch, but yours wouldn't be a big deal either, I think, as long as the add went forward without the hook execution when the server could not be contacted. Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBm8/HLD1OTBfyMaQRAk/LAJ9C6RM+GmI8dRsO2JTLatQp1XUC4ACgkzTO 9nJBYYY4EsgnEFAM1pyXINA= =/dsD -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
--- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: It's true that add and commit hooks can enforce the same kinds of policies as post-conditions of the commit. However, add hooks can enforce things like naming conventions. I'm working in a shop right now that prefers to have additions to the source tree (particularly new directories) be made by the architects of the project rather than the rank and file, and such a policy is best enforced at add time. The reason why I say these are best done at add time is because if the add succeeds then the user is likely to do a lot more work under the assumption that the subsequent commit will succeed (or at least not fail due to conditions created by the add). If the commit fails due to an improper add, then the user must re-do (or un-do) a bunch of work. All those hours of lost productivity could have been avoided by an add-time hook. This might be true, but it seems to me that most damage due to your lost productivity could be fixed with a rename or two and maybe a few `sed' runs, in a few minutes. At least in an environment where most of the files concerned were text files, as will usually be the case using CVS. It depends on the nature and extent of the changes. I can easily imagine scenarios in which lost productivity would be measured in days, even assuming that all files are ASCII. It might be interesting to see Greg's patch, but yours wouldn't be a big deal either, I think, as long as the add went forward without the hook execution when the server could not be contacted. The thing is, if there's a triggerable event, the trigger must be able to halt the event. Unplugging the network interface to enable adding a directory is simply not acceptable. On the other hand, requiring all add hooks to be replicated at commit time would eventually catch the error, and it could be argued that someone who attempts such tricks gets what they deserve, but it's just easier and better all around to just make the trigger act like a trigger. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question on modules file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yamuna Ramasubramaniyan [EMAIL PROTECTED] writes: I have a problem using a directory name with a space in it in the modules file. Can the modules file not support spaces in the directory name? Correct. Spaces in file and directory names are not well supported in CVS. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBmb+43x41pRYZE/gRArg3AJ99U5WICpjICQWygPaynnH+7EiZgwCg0bqx MdUpe9W33X8wGvuvIUTclHk= =htE2 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question regarding cvs admin
Hi, I read it on info-cvs how to change a branchname using cvs admin commands. I had to change a branch name and by accident I went into the repository(CVS ROOT) itself and executed the following command : cvs admin -nNew_Branch_Name:Old_Branch_Name And it gave me message saying Administering each module_name I am not sure if I erased some repositories or changed something. Please somebody tell me that nothing would have happened. Thanks in advance, Manasa ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question regarding cvs admin
Godavarthi, Manasa writes: I had to change a branch name and by accident I went into the repository(CVS ROOT) itself and executed the following command : cvs admin -nNew_Branch_Name:Old_Branch_Name And it gave me message saying Administering each module_name I am not sure if I erased some repositories or changed something. Please somebody tell me that nothing would have happened. It's hard to say. If you really did what you said, you should have gotten: cvs [admin aborted]: there is no version here; run 'cvs checkout' first So, either you're running a very old version of CVS, you didn't do what you said you did, or your repository is (or appears to be) checked out from another repository. -Larry Jones OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question on modules file
Hello, I have a problem using a directory name with a space in it in the modules file. I have the following line in my modules file: Docs -d Eng-us Docs_src/Help\ Files When I do cvs -d /home/cvs checkout Docs, I get an error: cvs [checkout aborted]: there is no repository /home/master/ycvs/Documentation-Eng-us/HTMLhelp_full_version/HTML\ If I make the modules file as Docs -d Eng-us Docs_src/Help Files I get: cvs [checkout aborted]: there is no repository /home/cvs/Docs_src Can the modules file not support spaces in the directory name? Thanks, Yamuna ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Pvcs2Rcs Script capability Question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please don't email me directly with CVS support questions unless you
are CC'ing the email list via a thread I've already entered
voluntarily. Normally that will get you my stock form letter
suggesting that you purchase CVS support from Ximbiot if you want to
be sure someone will be able to answer your CVS questions on a regular
basis. I manage to stay busy enough and don't normally have much
patience for people who think they are more likely to get a response
by mailing one of the CVS developers directly than by using the
mailing list or searching the mail archives. I'm making an exception
in this case only because I did enter this thread recently and I am
adding info-cvs to the CC list for the benefit of the email archives
and therefore posterity.
The first time I used the pvcs2rcs script, when I added capabilities
to convert branches and fixed several other bugs, I was running it on
Windows via MKS's UNIX toolkit and using ActiveState's port of Perl to
Windows, though that was many years ago and I expect the free Cygwin
UNIX tools for Windows and its Perl would work as well now.
You should be able to run the script on any system where you have
Perl, PVCS, RCS command line tools, regardless.
Please read the extensive comments in the header of the
contrib/pvcs2rcs(.in) file for more information on using the pvcs2rcs
script. Much of this information was already in there.
Cheers and thank you in advance for respecting my time and privacy in
the future,
Derek
Paras jain wrote:
!-- /* Font Definitions */ @font-face {font-family:Garamond;
panose-1:2 2 4 4 3 3 1 1 8 3;} /* Style Definitions */ p.MsoNormal,
li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt;
font-size:12.0pt; font-family:Times New Roman;} a:link,
span.MsoHyperlink {color:blue; text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed {color:purple;
text-decoration:underline;} span.EmailStyle17 {font-family:Arial;
color:windowtext;} @page Section1 {size:8.5in 11.0in; margin:1.0in
1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --
Hi Derek,
One Small Question? Can I convert the PVCS archives 6.8 on Windows
2000 to CVS archives in Linux from the script?
Because Script is on LINUX box and How I give it the windows archives ?
Thanks in advance
Pars
Derek
- --
*8^)
Email: [EMAIL PROTECTED]
Get CVS support at http://ximbiot.com!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBlM1GLD1OTBfyMaQRArgQAJ0ZJKF9o+p0xaqxnehcidwQddaJnwCeLLRy
5vyWK0OehKh2w1q9JCKsIYc=
=TE9x
-END PGP SIGNATURE-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
RE: question about rtag command.
Title: question about rtag command. That works for the trunk, but I was looking at being able to tag the status of a branch at a specified date/time. Harold -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Stuart StevensSent: Tuesday, November 09, 2004 5:08 PMTo: Lynch, Harold; [EMAIL PROTECTED]Subject: RE: question about rtag command. Normally you would use Cvs q rtag -D datestring new tag module to tag Stuart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lynch, HaroldSent: Tuesday, November 09, 2004 12:09 PMTo: [EMAIL PROTECTED]Subject: question about rtag command. Is it possible (with cvs 1.11.x) to tag a branch by date? I've tried a couple of permutaions of cvs -q rtag -r branchtag -D datestring modulename But I'm not sure if it is doing what I think it's doing. Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
question about rtag command.
Title: question about rtag command. Is it possible (with cvs 1.11.x) to tag a branch by date? I've tried a couple of permutaions of cvs -q rtag -r branchtag -D datestring modulename But I'm not sure if it is doing what I think it's doing. Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: question about rtag command.
Title: question about rtag command. Normally you would use Cvs q rtag -D datestring new tag module to tag Stuart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lynch, Harold Sent: Tuesday, November 09, 2004 12:09 PM To: [EMAIL PROTECTED] Subject: question about rtag command. Is it possible (with cvs 1.11.x) to tag a branch by date? I've tried a couple of permutaions of cvs -q rtag -r branchtag -D datestring modulename But I'm not sure if it is doing what I think it's doing. Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Merging question - from and to
Hi I have a question about merging. I thought merging with two -j options was 'from' revision and 'to' revision. This is what happened in my working area from trunk. I have a file soa.pc, branched out at 1.2, now at revision 1.2.4.1 on branch, and 1.2 on trunk. I check-out from trunk, then do cvs update -j 1.2.4.1 -j 1.2 soa.p Nothing happens. I then tried cvs update -j 1.2 -j 1.2.4.1 soa.pc RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.2.4.1 Merging differences between 1.2 and 1.2.4.1 into soa.pc I also tried in another way, cvs update -j Br_CRMR2a_Dev soa.pc Nothing. Then cvs update -j HEAD soa.pc RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.3 Merging differences between 1.2 and 1.3 into soa.pc I don't understand how this works? Is the order from-to or to-from or how are we supposed to give the -j options? Pls clarify. Thanks, Jeeva __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merging question - from and to
Jeeva Sarma [EMAIL PROTECTED] wrote: I have a file soa.pc, branched out at 1.2, now at revision 1.2.4.1 on branch, and 1.2 on trunk. I check-out from trunk, then do [ ... ] cvs update -j 1.2 -j 1.2.4.1 soa.pc Yes, like that. The command means, merge all changes that occurred between 1.2 and 1.2.4.1 into the working copy, which is what you want. What is confusing you is that there are *three* revisions involved: the base of the changes to merge, here 1.2, the endpoint of the changes to merge, here 1.2.4.1, and the working copy, which doesn't need to be called out by revision because it is the file sitting in your sandbox at the moment. In your case, the working copy is identical to the base, but this isn't always true. RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.2.4.1 Merging differences between 1.2 and 1.2.4.1 into soa.pc After which the soa.pc in your sandbox should be identical to 1.2.4.1, but once again this was a special case because your starting point was identical to 1.2 . cvs update -j HEAD soa.pc RCS file: /cvsrep/cvsroot/ACE/ace/audit/care/soa/soa.pc,v retrieving revision 1.2 retrieving revision 1.3 Merging differences between 1.2 and 1.3 into soa.pc If you omit the first -j, it defaults to the most recent common ancestor of the given -j and of the working copy. Here HEAD means 1.3, because you or someone else committed changes after you checked out the sandbox with 1.2 . The common ancestor of 1.3 and 1.2 is 1.2 so once again you end up with a special case where the base and the working revision are identical. You are grabbing the changes from 1.2 to 1.3 and injecting them in 1.2, the result being identical to 1.3 . BTW, if you lose track you can always do rm soa.pc cvs update soa.pc to get a clean copy of the HEAD of the moment. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question
Now, I was reading a material about CVS technology and I came across some doubts in concerns the some concepts: 1-To take place the transfer of the files stored in the repository q they were modified for your work area, through a sicronização operation. Like this, would to be in fact that sicronização operation? 2-CVS counts with a mechanism capable to control the simultaneous accesses and the parallel modifications, guaranteeing like this the integrity of the modifications and atomicity of the operations. Would be in fact that atomicity of operations? 3-CVS possesses mechanism capable to identify and to solve conflicts. However those identified conflicts are merely textual, not existing any analysis of the logical consistence. Here I didn't understand the expression textual conflicts very well. obs:those concepts were retired of the book CVS of Cristiano Caetano. ___ Yahoo! Messenger 6.0 - jogos, emoticons sonoros e muita diversão. Instale agora! http://br.download.yahoo.com/messenger/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question
Gleidson S? Barreto [EMAIL PROTECTED] wrote: 1-To take place the transfer of the files stored in the repository q they were modified for your work area, through a sicroniza??o operation. Like this, would to be in fact that sicroniza??o operation? I'm not sure what you mean, but... Synchronization in both direction has to be requested explicitly, by running a command. cvs update to receive changes made by others, and cvs commit to send changes made by you. 2-CVS counts with a mechanism capable to control the simultaneous accesses and the parallel modifications, guaranteeing like this the integrity of the modifications and atomicity of the operations. Would be in fact that atomicity of operations? If I remember correctly, commits are atomic within any one directory but are not atomic across entire hierarchies. Commits are certainly atomic on a file by file basis, so you do not get corrupted files. The lack of atomicity occurs when a developers performs an update (receive) while another developer performs a commit (send). The receiving developer may get an inconsistent snapshot with some files just before their commit and some other files just after the commit. The workaround is to repeat the update. It would be a little difficult to notice in practice, because when working on an active project one has to update many times every day. Also, the trunk tends to be somewhat unstable since it is being actively modified. 3-CVS possesses mechanism capable to identify and to solve conflicts. However those identified conflicts are merely textual, not existing any analysis of the logical consistence. Here I didn't understand the expression textual conflicts very well. A textual conflict occurs when two people modified lines at overlapping locations in a file, or at nearly overlapping locations (~3 lines apart or so). These conflicts have to be resolved manually. Modifications in distant parts of the file are accepted uncritically. You are correct that this could introduce logical errors in the merged file; the amazing thing is that it almost never does, because of the way people write software. In any case, cvs always gives you backup copies of the two conflicting versions of the file. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question about chacl
I'm trying to set permissions for a projectd using chacl and am unable because the initial cvs checkout is apparently not work. We have a large repository with many projects in place, and I've been using cvs checkout for months now, usually for deployments and tagging; but for some reason in this instance it is not working. Here's what I'm doing: cvs checkout -r HEAD ProjectName (This works fine) cvs chacl -R chacl cvsadmin:r ProjectName (This results in the following message:) cvs chacl: in directory .: cvs [chacl aborted]: there is no version here; do 'cvs checkout' first I can't even perform a simple listing of permissions using lacl on that project -- that command returns the same message. Any suggestions would be much appreciated. Some details: OS: Windows Server 2003 CVS: CVSNT 2.0.38 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question about chacl
Jeffrey, CVSNT has it's own mailing list: news://news.cvsnt.org/support.cvsnt Or http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt I suggest you ask there (and perhaps consider upgrading to the latest release): http://www.cvsnt.com Regards, Arthur Barrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JeffreyC Sent: Tuesday, 14 September 2004 10:40 AM To: [EMAIL PROTECTED] Subject: Question about chacl I'm trying to set permissions for a projectd using chacl and am unable because the initial cvs checkout is apparently not work. We have a large repository with many projects in place, and I've been using cvs checkout for months now, usually for deployments and tagging; but for some reason in this instance it is not working. Here's what I'm doing: cvs checkout -r HEAD ProjectName (This works fine) cvs chacl -R chacl cvsadmin:r ProjectName (This results in the following message:) cvs chacl: in directory .: cvs [chacl aborted]: there is no version here; do 'cvs checkout' first I can't even perform a simple listing of permissions using lacl on that project -- that command returns the same message. Any suggestions would be much appreciated. Some details: OS: Windows Server 2003 CVS: CVSNT 2.0.38 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
question about helping cvs performance.
Title: question about helping cvs performance. I'm getting complaints from the users about the amount of time it takes to do a tag or a branch (especialy the branch). Are there any standard things that can be done, or to watch out for, that would make these functions run as well as possible? Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
rtag question
Title: rtag question will the command: cvs -q rtag -D 2004-08-09 2:00 GMT -r SOMEBRANCHTAG SOMEMODULE put a tag on branch SOMEBRANCHTAG as the files were at 2am GMT on August 9th 2004 ? I was warned that tagging by date had problems on branches. The version of cvs we are using is 1.11.15. Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question about process scheduling - revisited.
Title: Question about process scheduling - revisited. I originally had a question about the way cvs server process get scheduled. Let me elaborate. The setup: Server: DELL dual intel processor (2.0 gig hertz). 4 gig ram 500 gig harddriver. Dual gigabit and 10t network interfaces. CVS 1.11.15 server on this machine (pserver is the connection method). Originally I thought it was a checkout time issue. But now I can see the occasional slow rtag. Normally it takes between 4 and 15 mintes to pull a sandbox, or about 15 minutes to rtag the same module. Occasionally we are seeing the checkout time jump to over 1 hour, or the rtag to take 2 hours. When I look at the server process on that corresponds to this slow moving command, I see that it seems to intermittenly get high then low cpu usage, and the total cpu time for that process keeps getting higher. But I've never seen it (in top) total peg the cpu's. Now this repository is about 3.5 years old, and quite large (over 40,000) files, lots of branches, etc. We've had the network people monitor that end, and they aren't seeing anything lost there. Does anybody have any ideas on what to look for here. Or is there pertanant information I have left out? Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question about RCS files
Hi. I am a CVS newbie and I would like to do/have the following: There is a Server with an CVS Repository sv in the path /var/lib/cvs/sv. On the clients I work with: CVSROOT=:ext:[EMAIL PROTECTED]:/var/lib/cvs; LOCAL=/SOMEWHERE/sv; CVS checkout is done by: cd /SOMEWHERE; cvs -d $CVSROOT checkout sv; CVS update is done by: cd /SOMEWHERE/sv; cvs -d $CVSROOT update -dP; CVS commit is done by: cd /SOMEWHERE/sv; cvs -d $CVSROOT commit; I describe all this because I dunno if you might need this information to answer me the following question: I thought that the CVS-Tree LOCAL and on the SERVER are IDENTICAL (after I did an update). But on the server the files end with ,v and have all the comments and version stuff inside. I now know that these files are the rcs files (the backbone of the cvs?). But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an client-like-copy of the cvs-repository in another dir? Thanks a lot for any help in advance! Greetings, K. Posern. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
K. Posern [EMAIL PROTECTED] writes: But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an client-like-copy of the cvs-repository in another dir? CVS doesn't have support for that. You'd have arrange to update any separate checked-out versions on the server yourself using a script. Take a look at the hooks like 'commitinfo' and loginfo' for ways to do that. -- Brian Gough Network Theory Ltd, Publishing the CVS Reference Manual --- http://www.network-theory.co.uk/cvs/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
Hi. I am a CVS newbie and I would like to do/have the following: On the clients I work with: CVSROOT=:ext:[EMAIL PROTECTED]:/var/lib/cvs; LOCAL=/SOMEWHERE/sv; CVS update is done by: cd /SOMEWHERE/sv; cvs -d $CVSROOT update -dP; CVS commit is done by: cd /SOMEWHERE/sv; cvs -d $CVSROOT commit; cvs -d $CVSROOT makes little sense... cvs uses $CVSROOT by default I describe all this because I dunno if you might need this information to answer me the following question: I thought that the CVS-Tree LOCAL and on the SERVER are IDENTICAL (after I did an update). But on the server the files end with ,v and have all the comments and version stuff inside. I now know that these files are the rcs files (the backbone of the cvs?). more or less. Never touch the files in $CVSROOT But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an client-like-copy of the cvs-repository in another dir? See keeping a checked-out copy https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 Arno ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
Hello, * On Thu, Aug 26, 2004 at 12:20:14PM +0200 K. Posern wrote: But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). Have a look at C.3.5.2 of your manual: https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 HTH, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Question about process scheduleing
Title: Question about process scheduleing I'm trying to look into a problem with the amount of time it takes us to do a checkout of a large (800 meg) module. On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. When I look at top on the cvs server, the process associated with the pulls to that machine get very little cpu. Is there any kind of scheduling going on inside the cvs server process (aside from blocking for io)? Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
K. Posern wrote: But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an client-like-copy of the cvs-repository in another dir? You have to do a cvs-checkout into a separate directory on the server, and then perform a cvs-update every time a client does a commit. In UN*X you can do the checkout on a cron job periodically. In Windows I think you can use cygwin to set up a cron job as well. You could also abuse the loginfo script so that after every commit the server runs a cvs update in you checked-out directory. See https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC167 Cheers, Andrew Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
Lynch, Harold wrote: I'm trying to look into a problem with the amount of time it takes us to do a checkout of a large (800 meg) module. On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. When I look at top on the cvs server, the process associated with the pulls to that machine get very little cpu. Is there any kind of scheduling going on inside the cvs server process (aside from blocking for io)? I had a problem like this that ultimately turned out to be a network card misbehaving, particularly with ssh. Andrew Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
Lynch, Harold wrote: I'm trying to look into a problem with the amount of time it takes us to do a checkout of a large (800 meg) module. On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. When I look at top on the cvs server, the process associated with the pulls to that machine get very little cpu. Is there any kind of scheduling going on inside the cvs server process (aside from blocking for io)? Harold Lynch Have you looked at top on the slow machine? You did not indicate if it has a bitty processor, compared to others, or if it has a lot of work happening on it all the time, or even if it has an old slow hard drive that the 800 meg is getting written to. Oh you are using :ext: or :pserver: access method right? Have you made sure the network connection to the slow machine is as fast as the others and in good repair? (Assuming Unix) check the output of ifconfig if the following are not 0 you might have a bad cable/hub/card errors:0 dropped:0 overruns:0 carrier:0 (not necessarily a good indicator, mine has a few here) check with ping `ping -c100 -s1492 slowmachine` if there is any loss in a LAN, something is going on you need to look into. `time ping -f -c1000 -s1492 slowmachine` for a slow processor machine on a 10Mb/s LAN the loss here should still be sub 20%. and running `time ping -f -c1000 -s1492` against a fast machine too might give you some insight. also the following might you measure the path. http://freshmeat.net/projects/netio/ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
Lynch, Harold writes: On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. Look for network problems with that machine -- that sounds like dropped packets and retransmissions. -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: WinCvs status window question
Menu-View-Output John E wrote: Just a clarification, I refereing to the output window when I said status window. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
WinCvs status window question
On my all but one of my Windows machines I can see the docked status window. On one, I cannot. How do you make this window visible? Thanks ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
WinCvs status window question
Just a clarification, I refereing to the output window when I said status window. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
commitinfo file question
Hi I have a question concerning commitinfo and project standards. Is it possible to run an app (called by commitinfo) against a particular file in a specific sandbox at commit time? I'm trying to prototype a stylechecker and don't want anyone but myself affected initially. If this is possible, does anyone have an example? TIA, -Tennis -- Remove -remove-to-reply to respond to my email address directly. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: commitinfo file question
At 12:41 PM 8/5/2004, Tennis Smith wrote: I have a question concerning commitinfo and project standards. Is it possible to run an app (called by commitinfo) against a particular file in a specific sandbox at commit time? I'm trying to prototype a stylechecker and don't want anyone but myself affected initially. Commitinfo scripts can see only the files that are being committed, unless you are running with a local repository. Then the script can see all of your files. It's probably easiest to create a new temporary and test your commitinfo script in there. You could also check $USER in the commitinfo script. Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: commitinfo file question
At 12:53 PM 8/5/2004, Frederic Brehm wrote: It's probably easiest to create a new temporary and test your commitinfo script in there. That should be a new temporary REPOSITORY Sorry, Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: commitinfo file question
Frederic Brehm [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] At 12:41 PM 8/5/2004, Tennis Smith wrote: I have a question concerning commitinfo and project standards. Is it possible to run an app (called by commitinfo) against a particular file in a specific sandbox at commit time? I'm trying to prototype a stylechecker and don't want anyone but myself affected initially. Commitinfo scripts can see only the files that are being committed, unless you are running with a local repository. Then the script can see all of your files. Ok. It's probably easiest to create a new temporary and test your commitinfo script in there. You could also check $USER in the commitinfo script. Good idea. Do you have an example of it? Thanks Frederic, -Tennis Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Update Question
Hi, I have a single file that's pivital to a project. Any time that file is updated, we need to do a re-compile of the components dependent on it. Is there any way to automatically drive the recompilation when the user does a cvs update on that central file? Any examples are welcome too. ;-) TIA, -Tennis -- Remove -remove-to-reply to respond to my email address directly. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Update Question
The most obvious suggestion to me is add a dependency rule to your makefile for this file that executes a cvs update important_file.c command. That way any time you do a make on the project, the critical file will be updated and recompiled if it has changed. For this to be useful, you must be able to interact with CVS without entering a password. How this is achieved depends on how you originally authenticated with CVS. Something like this should be added to your makefile: important_file.o: important_file.c cvs update important_file.c $(CC) $(CFLAGS) -c important_file.c YMMV depending on your project rules. Don't forget tabs are required to indent as shown above. Adam --- Adam Bernstein [EMAIL PROTECTED] http://mpgedit.org/~number6 Key fingerprint = E1 91 49 4C 24 18 E2 04 7A D3 78 A8 86 A9 7C 38 On Thu, 5 Aug 2004, Tennis Smith wrote: Hi, I have a single file that's pivital to a project. Any time that file is updated, we need to do a re-compile of the components dependent on it. Is there any way to automatically drive the recompilation when the user does a cvs update on that central file? Any examples are welcome too. ;-) TIA, -Tennis -- Remove -remove-to-reply to respond to my email address directly. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Import question
When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? Thanks, Michael ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import question
I had same problem some time back but don't have any solution to it.. you can go through http://lists.gnu.org/archive/html/info-cvs/2004-02/msg00077.html -Rohan Lemke, Michael IZ/HZA-IOP wrote: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? Thanks, Michael ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import question
Lemke, Michael IZ/HZA-IOP writes: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? Unfortunately, CVS doesn't have any convenient way to let you do that. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import question
Test BEFORE importing! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Larry Jones Sent: Thursday, July 22, 2004 10:12 AM To: Lemke,Michael IZ/HZA-IOP Cc: '[EMAIL PROTECTED]' Subject: Re: Import question Lemke, Michael IZ/HZA-IOP writes: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? Unfortunately, CVS doesn't have any convenient way to let you do that. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import question
From: Christopher.Fouts Sent: Thursday, July 22, 2004 4:22 PM To: [EMAIL PROTECTED] Subject: RE: Import question Test BEFORE importing! Sure but I need the merge of the local changes. But I can't get them without the import or can I? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Larry Jones Sent: Thursday, July 22, 2004 10:12 AM To: Lemke,Michael IZ/HZA-IOP Cc: '[EMAIL PROTECTED]' Subject: Re: Import question Lemke, Michael IZ/HZA-IOP writes: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? Unfortunately, CVS doesn't have any convenient way to let you do that. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import question
Can you export (not check out) the latest files you need from a current vendor branch, which should contain the changes you want (correct), add (not cvs add) your new files, test, and then import all the files to a new vendor branch? -chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Lemke, Michael IZ/HZA-IOP Sent: Thursday, July 22, 2004 10:36 AM To: [EMAIL PROTECTED] Subject: RE: Import question From: Christopher.Fouts Sent: Thursday, July 22, 2004 4:22 PM To: [EMAIL PROTECTED] Subject: RE: Import question Test BEFORE importing! Sure but I need the merge of the local changes. But I can't get them without the import or can I? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Larry Jones Sent: Thursday, July 22, 2004 10:12 AM To: Lemke,Michael IZ/HZA-IOP Cc: '[EMAIL PROTECTED]' Subject: Re: Import question Lemke, Michael IZ/HZA-IOP writes: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? Unfortunately, CVS doesn't have any convenient way to let you do that. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import question
-Original Message- From: Christopher.Fouts Sent: Thursday, July 22, 2004 4:43 PM Subject: RE: Import question Can you export (not check out) the latest files you need from a current vendor branch, which should contain the changes you want (correct), add (not cvs add) your new files, test, and then import all the files to a new vendor branch? Not sure I understand this. How could that put the changes I made to file X into the new vendor version of X? What would importing the stuff with something like cvs import -b 1.1.3 ... do? Currently, I am thinking of making a branch at the current HEAD, then import as usual. That way I have at least a chance to easily get a sandbox of the old version. BTW, I know which sandboxes exist so I am not very much concerned with concurrency. Michael -chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Lemke, Michael IZ/HZA-IOP Sent: Thursday, July 22, 2004 10:36 AM To: [EMAIL PROTECTED] Subject: RE: Import question From: Christopher.Fouts Sent: Thursday, July 22, 2004 4:22 PM To: [EMAIL PROTECTED] Subject: RE: Import question Test BEFORE importing! Sure but I need the merge of the local changes. But I can't get them without the import or can I? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Larry Jones Sent: Thursday, July 22, 2004 10:12 AM To: Lemke,Michael IZ/HZA-IOP Cc: '[EMAIL PROTECTED]' Subject: Re: Import question Lemke, Michael IZ/HZA-IOP writes: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? Unfortunately, CVS doesn't have any convenient way to let you do that. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lemke, Michael IZ/HZA-IOP [EMAIL PROTECTED] writes:
When I do a cvs import of a new vendor version the new files become the
head revision. I'd like to do the import such that it doesn't affect HEAD.
Only after I've tested the new stuff I want it to become HEAD. Of course,
it should work with local changes merged in just like the standard way of
doing it on the trunk. How can I do this?
A feature to deal with this was just added to the CVS feature branch
based on patches from Chris G. Demetriou. It is the 'cvs import -X'
switch which may be enabled by default using the option
ImportNewFilesToVendorBranchOnly=yes in the CVSROOT/config file.
If you checkout the top-of-tree cvs.cvshome.org ccvs module, you can
have a version of CVS with this feature.
However, Chris also provided a proof of concept set of shell scripts to
help you in the short term.
See http://lists.gnu.org/archive/html/bug-cvs/2004-06/msg00173.html
and http://lists.gnu.org/archive/html/bug-cvs/2004-06/txt5G0hQtIjfA.txt
If you hae already done other imports in your tree, you will need/want
to force a commit of the HEAD to be exactly the same as the previously
imported versions for now so that the stuff that works will all still be
visible. This will change the default branch from the vendor 1.1.1 to
the HEAD again. If you only have 1.1.1.1 versions from a single previous
import, you could just use 'cvs admin -b1' on those files instead of
forcing a checkin in preparation for a new cvs import.
Enjoy!
-- Mark
--- start of cvsimport_killnew ---
#!/bin/sh
# $Id: cvsimport_killnew,v 1.5 2003/01/16 01:27:55 cgd Exp $
# Script to kill revision 1.1 in files newly imported by CVS.
# See http://www.demetriou.com/~cgd/cvs for details.
#
# Written by Chris G. Demetriou [EMAIL PROTECTED]. Public domain.
fatal() {
echo '***' $0: ERROR: $1 12
exit 1
}
usage() {
echo usage: $0 logfilename 12
fatal usage
exit 1
}
if [ -z ${CVSROOT} ]; then
fatal CVSROOT is unset
fi
logfile=$1
if [ -z $logfile ]; then
usage
fi
if [ ! -f $logfile ]; then
fatal $logfile does not exist
fi
awk '/^N / { print $2 }' $logfile | (
set -e
while read file; do
repos_path=${CVSROOT}/${file},v
repos_dir=`dirname ${repos_path}`
repos_file=`basename ${repos_path}`
if [ ! -f $repos_path ]; then
echo Warning: $repos_path does not exist.
continue
fi
echo Fixing $file...
(
# XXX error handling in this block is bogus...
# a dir that won't (likely) be used.
mkdir -p $repos_dir/CVS
cd $repos_dir/CVS
# reset default branch.
rcs -b ../${repos_file}
# check in new rev w/ same contents.
co -l -M ../${repos_file}
ci -r1.2 -d -sdead \
-mrevision 1.1 was added on the vendor branch; delete
from trunk \
../${repos_file}
)
rmdir $repos_dir/CVS || true
echo Moving $file to the attic...
mkdir -p ${repos_dir}/Attic
mv ${repos_path} ${repos_dir}/Attic/${repos_file}
done
)
exit
--- end of cvsimport_killnew ---
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFA/9ot3x41pRYZE/gRAp8LAJ0ed5Ka5JFtHi2mxIGrjKFfsxni3ACghi01
OE240lCAnC7HNy0Lpct90s0=
=SrRT
-END PGP SIGNATURE-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Import question
From: Mark D. Baushke Sent: Thursday, July 22, 2004 5:16 PM To: Lemke, Michael IZ/HZA-IOP Cc: '[EMAIL PROTECTED]' Subject: Re: Import question -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lemke, Michael IZ/HZA-IOP writes: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? A feature to deal with this was just added to the CVS feature branch based on patches from Chris G. Demetriou. It is the 'cvs import -X' switch which may be enabled by default using the option ImportNewFilesToVendorBranchOnly=yes in the CVSROOT/config file. If you checkout the top-of-tree cvs.cvshome.org ccvs module, you can have a version of CVS with this feature. Hey, cool. Why wasn't that there in the first place? ;-) But I'll probably not grab it now but wait until it appears in the next 1.12.X release. However, this whole thing makes me realize I don't really understand vendor branches. What's different from ordinary ones? Just that the trunk helps itself to grab a version from it if it doesn't have one yet? The Cederqvist seems a bit short on it but maybe I should study it again. And what's that default branch stuff? However, Chris also provided a proof of concept set of shell scripts to help you in the short term. Thanks, but that's a bit too hot for me messing with the repository files directly. Anyway, thanks y'all for the quick help. Glad I asked. Michael ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lemke, Michael IZ/HZA-IOP [EMAIL PROTECTED] writes: However, this whole thing makes me realize I don't really understand vendor branches. What's different from ordinary ones? The vendor branch more closely models the RCS branching model. The initial import creates version 1.1 of a file and then 1.1.1.1 immediately afterward while at the same time changing the RCS branch to '1.1.1' and laying down a vendor tag label on the '1.1.1' RCS branch and the vendor version tag gets put onto 1.1.1.1. So, an imported version is always a real RCS branch. A cvs 'magic' branch has a tag name associated with a 'number' that looks like the base version of the file followed by the magical '.0' followed by an even number selected after looking at the other CVS 'magic' branch tags in the file. This 'magic' branch does not actually consume any delta record space in the RCS file until after you make a commit to the branch. This is also known as doing a 'lazy' allocation. Just that the trunk helps itself to grab a version from it if it doesn't have one yet? The Cederqvist seems a bit short on it but maybe I should study it again. And what's that default branch stuff? Mostly it is where the RCS view of the file collides with the CVS view of the world... If you really want to read more details, you probably need to dive into the doc/RCSFILES in one of the CVS releases and then read up in Cederqvist on RCS History and RCS, importing files from ... You may also find it helpful to read http://cvsbook.red-bean.com/cvsbook.html (although I can't recall how deeply Karl covered import and vendor related stuff in his book). However, Chris also provided a proof of concept set of shell scripts to help you in the short term. Thanks, but that's a bit too hot for me messing with the repository files directly. Yeah, I can understand that point of view too. :-) Anyway, thanks y'all for the quick help. Glad I asked. Michael Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA/+1W3x41pRYZE/gRAs8VAJ4wfNnR9za8QYWeJ5e946rRjibrkgCfeyf0 /LTsitM45+hqn1nYSdUNoAM= =UCYg -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Import question
Lemke, Michael IZ/HZA-IOP [EMAIL PROTECTED] wrote: When I do a cvs import of a new vendor version the new files become the head revision. I'd like to do the import such that it doesn't affect HEAD. Only after I've tested the new stuff I want it to become HEAD. Of course, it should work with local changes merged in just like the standard way of doing it on the trunk. How can I do this? There is no way to avoid that. Your trunk is broken between the time you do the import and when you merge the import back to the trunk. To mitigate the problem, you should tag your trunk before you do the import. If the post-import merge gives you trouble, you can at least start a branch off your pre-import tag so you can continue your work in another sandbox while you sort things out. When you finally merge the import, you go on to merge the temporary branch. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Commit and Add Question.
Hi all, I want to some operations after commit process is done. If I invoke cvs add, I do not do anything. Currently, I add the operation in loginfo file but my operations will get trigger if I run cvs commit or add. If I just want to trigger my operation once the cvs commit is done, how to do it? Thanks. -HS ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Commit and Add Question.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hon Seng Phuah [EMAIL PROTECTED] writes: I want to some operations after commit process is done. If I invoke cvs add, I do not do anything. Currently, I add the operation in loginfo file but my operations will get trigger if I run cvs commit or add. If I just want to trigger my operation once the cvs commit is done, how to do it? Thanks. https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC173 -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA84y53x41pRYZE/gRArAkAJ4xCJMwXGoaJvfPQO2hhhpAhYXVVQCePZ9Q AHBMphMw/bXpx2sEkaL0Gnc= =CjAK -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Diff question
How can I perform a diff between 2 dates in a given branch? I was hoping something like Branch:Date would work the same way it does for the `cvs up -j' option, but it is not recognized? Anything I'm missing? Manu PS: I'm using the client cvs 1.10.5 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Check out question.
My question is: I have four subdirectories in a CVS repository, such as: +-a |--b |--c |--d If the a/b/c module contains a few files. If I want to add new module using an empty hard drive, I will have to invoke cvs co a/b/c first. Only then I invoke cvs add directory command. Unfortunately, by invoke checkout command, it will checkout all a/b/c module files into my new hard drive. Is there a way to prevent checking out all module files into my new hard drive? Thanks. -HS Phuah ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Check out question.
Hon Seng Phuah writes: Unfortunately, by invoke checkout command, it will checkout all a/b/c module files into my new hard drive. Is there a way to prevent checking out all module files into my new hard drive? Use the -l option of checkout to prevent recursion. -Larry Jones I keep forgetting that rules are only for little nice people. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Cvs admin command question - using on files existing on branc h also
[EMAIL PROTECTED] wrote: Jeeva Sarma writes: I have a question using cvs admin command to delete a revision of a file. If I deleted revision 1.7 of a file, which also exists on a branch at that revision, what will be the status of that file on the branch? A revision cannot be on multiple branches. Revision 1.7 is on the trunk and only on the trunk. If you have a branch that's rooted at a particular revision, then I suspect that removing that revision would be a bad idea. Jeeva, this is where your experimental portion of your repository comes into play. I always recommend that you set up a directory in the repository, say $CVSROOT/cvs-test, with the understanding that anything in that directory can and will be deleted without notice. This allows you to experiment and see exactly what would happen in this case. I suspect Larry's probably right, though - it's probably not something you want to do ;-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
Title: branch removal question I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? If I need to supply more information please let me know, I would be glad to. Thanks, Don Butts -Original Message-From: Don Butts [mailto:[EMAIL PROTECTED]Sent: Friday, June 18, 2004 9:45 AMTo: [EMAIL PROTECTED]Subject: branch removal question We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. Thank you for your time, Don Butts ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
Don Butts wrote: I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? How about, this requires a few more brain cycles than were available at the time? :=) -Original Message- We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. I wouldn't remove the branches. I'm always reluctant to remove anything from the history. Instead of checking out branches, it might be easier to apply non-branch tags instead. This means fewer branches to deal with. I'm guessing the reason you're using a branch is because the update command remains the same, e.g. cvs update -r PROD (where PROD is a branch tag). Basically, what you would do is to create a non-branch tag indicating the currently-tested and working version, e.g. cvs tag REL_2_0_2. Then, you can move the PRODUCTION tag using the -F option to tag. Let me know if I'm not being clear (I haven't had my morning coffee yet ;-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: branch removal question
Don Butts wrote: Content-Type: multipart/mixed; boundary1243246784== Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. Confused, one or 2 CVSROOTs? do you mean `patch patchfile` or `cvs update -jsomething -jsomethingelse` (generally called a merge) When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time Why remove it? You loose history when you remove things (actually delete information from repo files), which is pretty much against having a version control system in the first place. why not create preprod`date +%Y_%b_%d` branches when you want to go into QA, so you have all the information that lead up to each release. (next question is a more personal process, not general practice) and why are the production releases not just (normal) tags on the QA branch(es), where the QA people have said this set of files is correct for release.? Of course you _might_ want to branch at that normal tag too if you need to do several fixes to the released version and then merge back to that QA branch when the fixes are ready to be QAed. I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. Thank you for your time, Don Butts -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
Normally one would apply a tag to the versions that are ready for testing, and update the tag as bugs are fixed. Then apply a second tag to the code that reaches production quality. To apply the second tag, use the cvs rtag -r option. The bummer with this is that if you make bug fixes in your test environment, you must run an additional cvs update command on each modified file due to stickiness issues in with the tags, but it's a minor annoyance that's overcome with experience. And you must remember to apply the testing tag to the committed fixes, a part of the process that might easily be forgotten. --- Forwarded mail from [EMAIL PROTECTED] I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? If I need to supply more information please let me know, I would be glad to. -Original Message- From: Don Butts [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 9:45 AM To: [EMAIL PROTECTED] Subject: branch removal question We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
--- Forwarded mail from [EMAIL PROTECTED] Don Butts wrote: I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? I wouldn't remove the branches. I'm always reluctant to remove anything from the history. Instead of checking out branches, it might be easier to apply non-branch tags instead. This means fewer branches to deal with. I'm guessing the reason you're using a branch is because the update command remains the same, e.g. cvs update -r PROD (where PROD is a branch tag). Basically, what you would do is to create a non-branch tag indicating the currently-tested and working version, e.g. cvs tag REL_2_0_2. Then, you can move the PRODUCTION tag using the -F option to tag. Floating tags can also be used. For example, create a tag called PRODUCTION and apply it to the next release. Then just run cvs update in the production area, and the proper versions will appear. The down side to this is that if you don't apply unique tags in addition to the floating one, you can't go back if something breaks. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
[EMAIL PROTECTED] wrote: Floating tags can also be used. For example, create a tag called PRODUCTION and apply it to the next release. Then just run cvs update in the production area, and the proper versions will appear. Yep, that's basically the idea I was trying to get across. The down side to this is that if you don't apply unique tags in addition to the floating one, you can't go back if something breaks. Yes, that's a very important point. So, to summarize, I think we're in agreement in recommending this procedure: There are two floating tags. For discussion's sake, I will call them: QA_VERSION PRODUCTION The tag QA_VERSION is applied to a version that is ready to go to QA. The tag PRODUCTION is applied to a version that is ready to go into production. When a version is ready for QA, a unique tag is applied. I usually recommend that the tag incorporates the version number and build number, e.g. for rev. 2.1 build 17 of a project named PROJECT, the tag might look like PROJECT_2_1_17. The QA_VERSION tag is applied to that version, using: cvs rtag -rPROJECT_2_1_17 -Ff QA_VERSION project (or, if you prefer, 'cvs tag -rPROJECT_2_1_17 -Ff QA_VERSION' ) When the QA version is ready for production, then the production tag is applied, using: cvs rtag -rQA_VERSION -F PRODUCTION project During the maintenance window, the QA version is promoted to production by simply issuing a 'cvs update -dP' command. Don, feel free to disagree or to point out anything we may have missed ;-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Cvs admin command question - using on files existing on branch also
I have a question using cvs admin command to delete a revision of a file. If I deleted revision 1.7 of a file, which also exists on a branch at that revision, what will be the status of that file on the branch? Some files exist on trunk and also branch, and we want to rollback some revisions for these files only on the branch, is there anyway we can use the cvs admin command for to achieve this? Or should we do it manually? Thanks for any insights. --Jeeva __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Cvs admin command question - using on files existing on branch also
Jeeva Sarma writes: I have a question using cvs admin command to delete a revision of a file. If I deleted revision 1.7 of a file, which also exists on a branch at that revision, what will be the status of that file on the branch? A revision cannot be on multiple branches. Revision 1.7 is on the trunk and only on the trunk. If you have a branch that's rooted at a particular revision, then I suspect that removing that revision would be a bad idea. Some files exist on trunk and also branch, and we want to rollback some revisions for these files only on the branch, is there anyway we can use the cvs admin command for to achieve this? Or should we do it manually? Neither. You should use update with two -j options to remove the revisions in question and then commit the result as a new revision: https://www.cvshome.org/docs/manual/cvs-1.11.16/cvs_5.html#SEC62 -Larry Jones When you're SERIOUS about having fun, it's not much fun at all! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
branch removal question
Title: branch removal question We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. Thank you for your time, Don Butts ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: newbie question on initializing repository
Chris, I've had some issues with my email so I'm just now seeing your response. Thanks for taking the time to write up the shell script. Looks like a nice way to do it. I guess it boils down to whether its possible to determine the type of a file from its name. Though as I think about it, I could replace your if statement with a call to the UNIX file command and then it wouldn't be name dependent. But it would be dependent on how good a job the file command does and I've seen it get things wrong. Bret Cooper ---original message-- Date: Mon, 7 Jun 2004 17:17:10 -0400 From: [EMAIL PROTECTED] Subject: RE: newbie question on initializing repository To: [EMAIL PROTECTED] In this case, I'd import a blank project, and then use cvs add in a script to add the files, using the -kb option accordingly. Here's a c-shell pseudo-code # Assume *.h and *.cpp files are text files, and the rest are binary files... for f in `find .`; then if [ -f $f ]; then # found a file, test if binary if [ $f == *.h || $f == *.cpp ]; then # add binary file cvs add -kb $f; else # add text file cvs add $f; else if [ -d $f ]; then # add directory cvs add $f; fi; fi; done You get the idea. Gurus may have a better solution though -chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bret A Cooper Sent: Monday, June 07, 2004 4:47 PM To: [EMAIL PROTECTED] Subject: newbie question on initializing repository Hello, This is a first time user question. We have collected all of our source files within a directory structure and are ready to initialize the cvs repository. There are a couple thousand files. Roughly 20% are binary type files and are scattered around throughout various directories. My original plan was to run the cvs init command from the topmost directory and be done. However, I now believe its not that simple, as the binary files(only) must be initialized with the -kb option. Is that correct? If so, any suggestions on the simplest/easiest to go about this? Thanks, Bret Cooper ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
View List of CVS Tags (basic question)
Hello, I wonder if anyone can help me. I am after a list of Tags made in CVS. Looking at the documentation I got the impression I should be viewing the Taginfo file, but it doesn't give me the information that I want. Can anyone help me please because I think I am well off the mark at the moment. intY has scanned this email for all known viruses (www.inty.com) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: View List of CVS Tags (basic question)
Iain Freeston [EMAIL PROTECTED] writes: I am after a list of Tags made in CVS. Looking at the documentation I got the impression I should be viewing the Taginfo file, but it doesn't give me the information that I want. A list of tag names is stored in the CVSROOT/val-tags file in the repository. -- Brian Gough Network Theory Ltd, Publishing the CVS Reference Manual --- http://www.network-theory.co.uk/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: View List of CVS Tags (basic question)
Iain Freeston wrote: Hello, I wonder if anyone can help me. I am after a list of Tags made in CVS. Looking at the documentation I got the impression I should be viewing the Taginfo file, but it doesn't give me the information that I want. Can anyone help me please because I think I am well off the mark at the moment. You're right, you are well off the mark ;-) taginfo is a hook that allows you to run a specific script when 'cvs tag' or 'cvs rtag' commands are invoked. If all you want is exactly what you said - a listing of all tags in the repository - then you can use Brian's suggestion of looking at val-tags. Be aware that val-tags shows all the tags ever applied to any file in the repository; tags are never removed. It also does not differentiate between different modules (which really limits its usefulness, IMO). Another way to get the tags for a specific project or a specific set of files is to use 'cvs log -h' or 'cvs status -v'. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: View List of CVS Tags (basic question)
Jim.Hyslop writes: Be aware that val-tags shows all the tags ever applied to any file in the repository No, it doesn't. It shows all the tags that have been used to *retrieve* files from the repository since the val-tags file was created. It's just an optimization -- you can delete it at any time and CVS will simply recreate it and continue to function normally. You should never rely on it for anything. -Larry Jones All this was funny until she did the same thing to me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: View List of CVS Tags (basic question)
Brian Gough writes: A list of tag names is stored in the CVSROOT/val-tags file in the repository. But it's not complete. It's just a cache for optimization purposes. -Larry Jones Everything's gotta have rules, rules, rules! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: View List of CVS Tags (basic question)
Iain Freeston writes: I am after a list of Tags made in CVS. Tags are kept in the individual RCS files, there's no central database of them. You can find the tags on a particular file with the log command or with status -v. -Larry Jones I stand FIRM in my belief of what's right! I REFUSE to compromise my principles! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
newbie question: CVS server upgrade
Hello everyone, I am reasonably new to CVS and am looking for some tips/handy hints for upgrading the CVS server. can anybody give me any help or advice please ? my OS is : SunOS xultra1 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-2System = SunOS Node = xultra1 Release = 5.8 Thanks in advance ! Mark. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: newbie question: CVS server upgrade
Download the latest source, unpack it, cd into the directory: ./configure make su make install (Some systems allow sudo make install) HTH Alex Am 10.06.2004 um 12:16 schrieb mark hanna: Hello everyone, I am reasonably new to CVS and am looking for some tips/handy hints for upgrading the CVS server. can anybody give me any help or advice please ? my OS is : SunOS xultra1 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-2System = SunOS Node = xultra1 Release = 5.8 Thanks in advance ! Mark. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: newbie question: CVS server upgrade
Alex v.Below writes: Download the latest source, unpack it, cd into the directory: ./configure make su make install cvs init It hasn't been strictly required so far, but it's a good idea. It gives the new CVS a chance to update the existing repository should the format change, add new administrative files, etc. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: newbie question on initializing repository
Hello, * On Mon, Jun 07, 2004 at 05:34:02PM -0400 Larry Jones wrote: However, I now believe its not that simple, as the binary files(only) must be initialized with the -kb option. Is that correct? If so, any suggestions on the simplest/easiest to go about this? If you can distinguish the binary files from the text files by their names (e.g., *.gif files are always binary), you can use the CVS wrappers facility to automatically handle the files correctly To add to this: If the text files are Unix-style (LF only), I also had success in importing everything as binary, and changing the text files to text afterwards with cvs admin. If the text files are Windows style, doing a dos2unix on them, and then treating it as in the above case, works, too. Best regards, Spiro. -- Spiro R. Trikaliotis I'm subscribed to the mailing lists I'm posting, http://www.trikaliotis.net/ so please refrain from Cc:ing me. Thank you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
newbie question on initializing repository
Hello, This is a first time user question. We have collected all of our source files within a directory structure and are ready to initialize the cvs repository. There are a couple thousand files. Roughly 20% are binary type files and are scattered around throughout various directories. My original plan was to run the cvs init command from the topmost directory and be done. However, I now believe its not that simple, as the binary files(only) must be initialized with the -kb option. Is that correct? If so, any suggestions on the simplest/easiest to go about this? Thanks, Bret Cooper ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: newbie question on initializing repository
Title: Message In this case, I'd import a blank project, and then use "cvs add" in a script to add the files, using the -kb option accordingly. Here's a c-shellpseudo-code # Assume *.h and *.cpp files are text files, and the rest are binary files... for f in `find .`; then if [ -f $f ]; then # found a file, test if binary if [ $f == *.h || $f == *.cpp ]; then # add binary file cvs add -kb $f; else # add text file cvs add $f; else if [ -d $f ]; then # add directory cvs add $f; fi; fi; done You get the idea. Gurus may have a better solution though -chris -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bret A CooperSent: Monday, June 07, 2004 4:47 PMTo: [EMAIL PROTECTED]Subject: newbie question on initializing repositoryHello, This is a first time user question. We have collected all of our source files within a directory structure and are ready to initialize the cvs repository. There are a couple thousand files. Roughly 20% are binary type files and are scattered around throughout various directories. My original plan was to run the cvs init command from the topmost directory and be done. However, I now believe its not that simple, as the binary files(only) must be initialized with the -kb option. Is that correct? If so, any suggestions on the simplest/easiest to go about this? Thanks, Bret Cooper ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: newbie question on initializing repository
Bret A Cooper writes: My original plan was to run the cvs init command from the topmost directory and be done. I think you mean cvs import -- init just creates a repository, it does not populate it with user files. However, I now believe its not that simple, as the binary files(only) must be initialized with the -kb option. Is that correct? If so, any suggestions on the simplest/easiest to go about this? If you can distinguish the binary files from the text files by their names (e.g., *.gif files are always binary), you can use the CVS wrappers facility to automatically handle the files correctly -- see the manual for details (and note that you can specify -W as many times as you need to on the import command): https://www.cvshome.org/docs/manual/cvs-1.11.16/cvs_18.html#SEC166 -Larry Jones Oh yeah? You just wait! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
basic question
Hello, I'm new to CVS andI would like to install a cvs server on a linux worksation and a cvs client on a WinXP workstation. I would like to access the cvsserver with a secure protocol. What are the tools (cvs, wincvs, cvsnt, ...) and protocol (gserver, ssh,...) which are required or best suited for this application ? Thanks for any help. Jean ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Fwd: basic question
If you only have known users, and all users have both read/write access, I suggest pure ssh. Please check the cvs documentation how to set this up, if you know how to set up ssh connections, it is really easy. If you need to control read/write permissions, I suggest a pserver combined with an ssh tunnel. The archives of this group should give you ample info on this. As to anonymous read access, I pass the question to the rest of the group. I have no experience with this as it is none of my requirements. HTH Alex Am 03.06.2004 um 14:09 schrieb Jean LEE: Hello, I'm new to CVS and I would like to install a cvs server on a linux worksation and a cvs client on a WinXP workstation. I would like to access the cvs server with a secure protocol. What are the tools (cvs, wincvs, cvsnt, ...) and protocol (gserver, ssh,...) which are required or best suited for this application ? Thanks for any help. Jean ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Version numbers question
Hi Sorry for the long mail. I have 2 questions about version numbers. First, is there any limit on the number of versions we can have for a file in cvs? Suppose we keep updating a file from 1.1. If there are 200 revisions, will it be 1.200 and so on? Upto what number does it get incremented? will it ever be 2.1 and so on without our explicitly making it so using the -r on check-in? And I have a question about 2 files that are on the same branch and have logs as below RCS file: /cvsrep/cvsroot/OP/op/asos/src/java/com/sbc/orderprocessor/orderEngineAdapter/OEAdapter.java,v Working file: OEAdapter.java head: 1.1 branch: 1.1.1 locks: strict access list: symbolic names: op_crm1_052504_preprod: 1.1.1.1 op_crm1_051704_QC: 1.1.1.1 op_crm2a-1_050504_QC: 1.1.1.1 Br_04-20-04_CRMR2a_Dev: 1.1.1.1.0.4 Tag_04-20-04_CRMR2a_Dev: 1.1.1.1 Tag_03-30-04_CRMR1_Prod: 1.1.1.1 start: 1.1.1.1 yoyo: 1.1.1 keyword substitution: kv total revisions: 3; selected revisions: 3 description: revision 1.1 date: 2004/03/30 23:10:32; author: mt5921; state: Exp; branches: 1.1.1; Initial revision revision 1.1.1.1 date: 2004/03/30 23:10:32; author: mt5921; state: Exp; lines: +0 -0 branches: 1.1.1.1.4; WR# TAR# Initial check-in for OP revision 1.1.1.1.4.1 date: 2004/05/15 18:09:10; author: sc5869; state: Exp; lines: +3 -0 Task312: WR#4146 TAR#3878 Made Changes to the OEAdapter.java files for populating new schemas - 2nd file: RCS file: /cvsrep/cvsroot/OP/op/asos/src/java/com/sbc/orderprocessor/asiTranslator/Processor.java,v Working file: Processor.java head: 1.7 branch: locks: strict access list: symbolic names: op_crm1_052504_preprod: 1.7 op_crm1_051704_QC: 1.6 op_crm2a-1_050504_QC: 1.4 Br_04-20-04_CRMR2a_Dev: 1.4.0.2 Tag_04-20-04_CRMR2a_Dev: 1.4 Tag_03-30-04_CRMR1_Prod: 1.1.1.1 start: 1.1.1.1 yoyo: 1.1.1 keyword substitution: kv total revisions: 9; selected revisions: 9 description: revision 1.7 date: 2004/05/21 00:02:49; author: rt5647; state: Exp; lines: +19 -11 Task375: WR#3626c TAR#3737 spread the orders across all channels and sub channels revision 1.6 date: 2004/05/18 00:50:01; author: sy5429; state: Exp; lines: +4 -2 Task345: WR#3626c TAR#3914 Removed some extra verbose debugging messages revision 1.5 date: 2004/05/17 21:13:01; author: sy5429; state: Exp; lines: +44 -157 Task332: WR#3626c TAR#3914 Modified to use digests for performance enhancements revision 1.4 date: 2004/04/15 22:30:38; author: sy5429; state: Exp; lines: +33 -24 branches: 1.4.2; Task20: WR#3626c TAR#3363 Performance testing fixes Task20: - Added the code to split the orders into n channels configurable through Task20:the configFile Task20: revision 1.3 date: 2004/04/15 18:08:28; author: sy5429; state: Exp; lines: +166 -65 Task13: Task12: Task11: WR#3525c TAR# Task13: Task12: Task11: - To fix the issue where response listener sits idly, processing nothing Task13: Task12: Task11: - To split the orders n-way between n channels configurable through configFile.zml Task13: Task12: Task11: - To add the HostName to the subject of the NotifyHandler emails Task13: Task12: Task11: revision 1.2 date: 2004/04/01 21:43:30; author: sy5429; state: Exp; lines: +821 -647 WR#3626c TAR# - Changed the code to conform to the restructured job scheduler APIs revision 1.1 date: 2004/03/30 23:10:33; author: mt5921; state: Exp; branches: 1.1.1; Initial revision revision 1.1.1.1 date: 2004/03/30 23:10:33; author: mt5921; state: Exp; lines: +0 -0 WR# TAR# Initial check-in for OP revision 1.4.2.1 date: 2004/05/08 22:35:16; author: sy5429; state: Exp; lines: +7 -18 Task284: WR#4146 TAR#3709 Fixed the code to not filter out the SNET orders For Processor.java, looks like there was already a branch when I made the initial import (1.1.1.1.4)? How can that be? I don't understand what went wrong..Can someone explain this? Thanks a lot. Mala __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Version numbers question
Mala T writes: I have 2 questions about version numbers. First, is there any limit on the number of versions we can have for a file in cvs? Only the maximum value of an integer on your system and the amount of disk space you have available to hole the repository. will it ever be 2.1 and so on without our explicitly making it so using the -r on check-in? No. For Processor.java, looks like there was already a branch when I made the initial import (1.1.1.1.4)? No, the branch was created after the import. Since you hadn't made any local changes to the file before the branch was created, the branch was rooted at the imported version on the vendor branch rather than being rooted on the trunk. That's perfectly normal and nothing to worry about. -Larry Jones That gives me a FABULOUS idea. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Fwd: basic question
Alex v.Below writes: If you need to control read/write permissions, I suggest a pserver combined with an ssh tunnel. There's usually no need for such complication, just use pure ssh with normal OS permissions to control access. -Larry Jones What a waste to be going to school on a morning like this. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Branch/merge question....
Hi, I have a rather specific issue here: Suppose we have created a branch for a development in our module called branch_A for a longer time. During the development we have decided to intagrate all changes on the main branch into branch_A (and we have tagged both the main/HEAD and the branch). After completing the task, we are to integrate the branch into the main, but the second merging brings out a rather annoying number of conflicts. The situation is the same when we try to merga main into branch_A again. As far as I know, the merge algorithm uses the younges common ancestor of the source files. Am I able to set the merga base to the last successfull integration? I recon this would blow away some of our conflicts.. Thx in advance, Gabaux Linux is like a wigwam: no gates, no windows, and an apache inside! ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
