[darcs-users] Conventions on teams using darcs - naming, patch size, etc.
Matt Lamari
matt.lamari at gmail.com
Wed May 23 00:36:59 UTC 2012
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.
More information about the darcs-users
mailing list