There's the problem of project gates. Currently I manage such a gate and I push the fixes it contains to ON regularly. Until I do so I have one changeset per CR, however, pushing to ON requires collapsing the changesets. At that point you get several unrelated CRs in one changeset.
- Jose > -----Original Message----- > From: on-discuss-bounces at opensolaris.org [mailto:on-discuss- > bounces at opensolaris.org] On Behalf Of Milan Jurik > Sent: Friday, September 26, 2008 7:30 AM > To: James Carlson > Cc: on-discuss at opensolaris.org > Subject: Re: [on-discuss] hg comments > > 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 > > > _______________________________________________ > on-discuss mailing list > on-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/on-discuss
