[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