ccvs 3.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138
  1. * CVS Access
  2. If you are an active Mono developer, you can get a CVS account
  3. that hosts the Mono source code.
  4. If you are not a developer, but want to track the development, please
  5. see the <a href="anoncvs.html">AnonCVS</a> instructions.
  6. Send an e-mail to miguel with your public SSH key for this
  7. purpose. Please specify if the key was generated with SSH1 or SSH2.
  8. If you are using SSH2, please generate your key using:
  9. <pre>
  10. ssh-keygen -t rsa
  11. </pre>
  12. And mail me the id_rsa.pub file.
  13. If you are using SSH1, run:
  14. <pre>
  15. ssh-keygen
  16. </pre>
  17. And mail me your identity.pub file.
  18. You will need CVS and SSH. Windows users can get both by
  19. installing Cygwin (<a
  20. href="http://www.cygwin.com">http://www.cygwin.com</a>)
  21. Unix users will probably have those tools installed already.
  22. ** Checking out the sources
  23. To check out the sources for the first time from the
  24. repository, use this command:
  25. <pre>
  26. export CVS_RSH=ssh
  27. export [email protected]:/cvs/public
  28. cvs -z3 co mcs mono
  29. </pre>
  30. ** Updating your sources
  31. Every day people will be making changes, to get your latest
  32. updated sources, use:
  33. <pre>
  34. cvs -z3 update -Pd mcs mono
  35. </pre>
  36. Note: The '-z3' enables compression for the whole cvs action.
  37. The '-Pd' makes the update operation (P)rune directories that
  38. have been deleted and get new (d)irectories added to the
  39. repository.
  40. ** Making patches
  41. Usually you will want to make a patch to contribute, and let
  42. other people review it before commiting it. To obtain such a
  43. "patch", you type:
  44. <pre>
  45. cd directory-you-want-to-diff
  46. cvs -z3 diff -u > file.diff
  47. mail [email protected] < file.diff
  48. </pre>
  49. ** Keeping track of changes.
  50. We provide two e-mail based mechanisms to keep track of
  51. changes to the code base:
  52. <ul>
  53. * <a href="mailto:[email protected]">
  54. [email protected]</a>: This mailing list receives
  55. in patch form all the changes that are being made to the
  56. CVS.
  57. * <a href="mailto:[email protected]">
  58. [email protected]</a>: This mailing list only
  59. receives the CVS commit logs with a list of files
  60. modified.
  61. </ul>
  62. We hope to offer LXR and Bonsai in the future as well.
  63. ** Commiting your work
  64. Once you get approval to commit to the CVS, or if you are
  65. commiting code that you are the maintainer of, you will want
  66. to commit your code to CVS.
  67. To do this, you have to "add" any new files that you created:
  68. <pre>
  69. cvs add new-file.cs
  70. </pre>
  71. And then commit your changes to the repository:
  72. <pre>
  73. cvs commit file-1.cs file-2.cs
  74. </pre>
  75. ** The Mailing List
  76. To keep track of the various development and changes to the
  77. CVS tree, you can subscribe to the [email protected].
  78. To subscribe, send an email message to
  79. [email protected] and in the body of the
  80. message put `subscribe'.
  81. This will send you an email message every time a change is
  82. made to the CVS repository, together with the information that
  83. the author of the changes submitted.
  84. ** Recommendations
  85. Please do not commit code that would break the compile to the
  86. CVS, because that normally wastes everybody's time. Two things
  87. are important in this step: trying to build your sources and making
  88. sure that you add all the new files before you do a commit.
  89. To build the sources, most of the type trying the `make' command
  90. is enough. In some cases (the class libraries) we use nant, so
  91. you need to run nant manually.
  92. Use ChangeLog entries so we can keep textual descriptions of
  93. your work, and use the contents of your ChangeLog file as the
  94. CVS commit message (ie, paste the contents of this into the
  95. editor buffer).
  96. If you are making changes to someone else's code, please make
  97. sure you get in touch with the maintainer of that code before
  98. applying patches. You want to avoid commiting conflicting
  99. work to someone else's code.