Are there any conventions that users tend to gravitate towards? 1. Naming - with patches from a lot of people, do short names like : "Fixed the serialization of Foo" work? Do long names wrap a line telling exactly what you did work better? Or do you fall back on bug numbers? What if you can't fall back on issue numbers? Does pinpointing a patch by name or in some context get tricky? 2. Change granularity - do people tend to try to split a change up into parts, e.g. if a library and end-code are in the same repo, maybe patch the lib first and then the rest adding it as a dependency? 3. Merging patches. . . Does pollution of lots of tiny little changes ever become a problem, or something you address in practice? For example, say people all work on some related issue, put in lots of little fixes, then you're done - is it ever something where you want to just merge them all and have everyone work in terms of the amended repository? Or does the UI/history/etc. make it easy to find, or not find if you don't want the clutter, the aggregate of compound changes?
Any ideas, thoughts, experience on how people tend to handle long-lived group projects, with Darcs, appreciated. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
