Hi James, James Carlson p??e v P? 26. 09. 2008 v 08:48 -0400: > Milan Jurik writes: > > Maybe it should be prohibited to push unrelated CRs in one changeset > > (and RTI)? It will help with many things, e.g. regression hunting and > > backports. It isn't so huge problem with Mercurial to move changesets > > between workspaces if you are working on several CRs in parallel. Today > > we have some huge-list-CRs changesets in one subsystem which have no > > reason to go together. > > "Prohibit" seems extreme to me. There are sometimes good reasons > (such as test considerations and things that are fixed as side-effects > of some larger restructuring) to put multiple apparently-unrelated CRs > into one changeset. Forcing a breakup will force submitters to run > expensive (and redundant) tests on each CR individually, and in some > cases (such as restructuring) may not actually be possible at all. >
I fully understand this "test considerations" but you should also count those additional costs I mentioned. Yes, invisible for contributor on the first look. If suggested fix is done per CR, then it's good and just a bit of manual work to split changeset (but not easy to do bisect), but that isn't 100% cases. I agree there are many cases where multiple CRs, on one look unrelated, can be related on the second. > It seems good to encourage people mixing apples and oranges not to do > so, but it also doesn't seem to me that's actually a problem in ON. > (Can you cite cases where we really do have huge changesets that have > absolutely *no* reason at all to go together?) > After Mercurial start it didn't happen yet, at least not in areas I'm interested in. In teamware time you can meet long-list non-project putbacks, but usually it wasn't problem because they touched different files and they marked them. No record in my inbox now, but if you really want, I could look. > Instead, I think people are just going through the pain of getting > used to a new source code management system. It isn't SCCS, and it > works differently. We're going to have to get used to the fact that > the new system doesn't normally give you per-file comments, so (more > than ever) you do have to look at the CRs to understand the bits. And > that means (more than ever) making sure that CRs are updated properly. > Yes. If this is enforced by CRT advocates, then big changesets can create only problem during bisect. > In fact, for backports, I think this is actually a healthy change. It > used to be easier to cherry-pick a single SCCS delta for a single CR > (out of one of those big Teamware putbacks that have always been > common) to backport to a previous release. However, as the fix for > that one CR likely had never actually been tested in isolation, and > the whole wad was soaked in the marketing release as one unit, the > idea of doing that individual backport was a bit sketchy, and possibly > even just plain wrong. > One way to look at it. As opposite, many fixes in one backport are leading to many regressions. Yes, support is about "cherry-picking". Don't forget that even if you will take the whole changeset, you aren't taking all changesets, so backport "together" isn't valid point and doesn't decrease amount of work or improve quality. The decision "what's related and what isn't" is very subjective. Personally I would prefer in one changeset only cross=depending CRs but I am alone probably :-) Best regards, Milan
