Re: RV: Newbie question. How to manage replaced files
Spiro: Unified diff format will not solve the posters problem of safely committing arbitrary files. It will also create more work. As Pierre stated, Nestor should implement tighter guidelines for obtaining and submitting sources. This can be difficult if dealing with 3rdparty dev-co's (or internal management...) Anyhow, a possible solution is to ask that the entire _affected_ source tree with CVS info included be sent to you in an archive. (only include directories containing changed files.) Of course this means that you must ship a CVS tree to them to edit... but where else would they get the code? This is the only way to be able to safely check in changed code: - check out source modules that will be modified - tag these sources with a branch if you think they will break the head when merging - archive the sources - ship to modifier - recieve from modifier - add a safty tag (if you chose not to branch) - add changes on branch (or head if you chose not to branch) - build and test - merge changes into head if it was a success Really tho, this is a process problem. Not a cvs problem. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: RV: Newbie question. How to manage replaced files
Hello, * On Sun, Jan 30, 2005 at 09:47:30PM + Pierre Asselin wrote: If you can't determine the revision or tag from which to branch, you probably need to tighten your controls a little... Another possiblity is to tell all your external contributors to send in only patches, never the complete source file. I would suggest the unified diff format (-u). You would have to patch these diff files into your working copies. Furthermore, it is not you who must determine the version the external contributor used, but the contributor himself has to find this out. Regards, Spiro. -- Spiro R. Trikaliotis http://cbm4win.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RV: Newbie question. How to manage replaced files
Hi I have been using CVS for some time and have encounter problems when somebody gives me a file that I have to replaced in my CVS sandbox. This always happens because sometimes I have people outside the organization and they send new versions of files that I have to replace in the sandbox and try to update and commit to the CVS Repository. What is the best way to manage this case? Regards, Néstor Boscán ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: RV: Newbie question. How to manage replaced files
N?stor Bosc?n [EMAIL PROTECTED] wrote: I have been using CVS for some time and have encounter problems when somebody gives me a file that I have to replaced in my CVS sandbox. This always happens because sometimes I have people outside the organization and they send new versions of files that I have to replace in the sandbox and try to update and commit to the CVS Repository. What is the best way to manage this case? I would figure out what revision of the file the external user started with. Then I would create a branch at that revision, commit the modification to that branch and see if I can merge the branch back to the trunk. By extension, if people send you patch of the entire source tree, *based on a released version*, you can branch the entire tree off the corresponding release tag, apply the patch, commit, and decide whether you want to merge the branch. If you can't determine the revision or tag from which to branch, you probably need to tighten your controls a little... -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
