Re: [lmi] New interim branch 'branch-20061115', and some cvs questions

[Greg Chicares]

On 2006-11-16 1:07 UTC, Vadim Zeitlin wrote:
> On Wed, 15 Nov 2006 18:11:46 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> The main trunk contains a release candidate that's being tested
> GC> right now, so I've created a new branch for development in the
> GC> interim. I'm thinking that we ought to do this regularly, using
> GC> names generated as 'branch-YYYYMMDD' for consistency (it seems
                                         ^Z [avoid timezone problems]
> GC> unnecessary to create two branches on the same day),
                               ^such special

I ported the contents of 'gnome-xml-branch' to HEAD. It wasn't a
literal merge. I renamed some files. I modified some code. I
left out some things that later discussions rendered unnecessary
(e.g., we decided to install new xml files to the same location
as wxxrc files, and not somewhere special like /usr/local/sgml/).
So 'gnome-xml-branch' is defunct; or its only remaining use is
for verifying that I ported everything correctly.

And HEAD is temporarily frozen for testing.

Evgeniy seeks a place to commit changes he wants to share now,
perhaps including corrections to the porting work that I did. So
where? I figure we may have that question every month; above is
a proposed answer to that question only.

>  I don't see why shouldn't it be possible to create 2 branches per day, for
> example if 2 persons start working on different subprojects simultaneously.

Certainly. That's okay.

I assert only that the situation I described above cannot occur
twice in one day. We won't start a formal testing cycle twice
in the same day.

> And while this could be fixed by using "branche-YYYYMMDDHHMMSS" format, I
> also believe that symbolic names for branches are more useful than
> timestamps as they explain much better what changes were done on that
> branch.

I propose only that we use 'branch-YYYYMMDDZ' in the situation
described above, not in any other situation. I'm open to other
proposals to solve that special problem.

For other purposes, a session like this:

  [datetime=20061116T1314Z]$cvs rtag -b some-new-widget lmi
  [datetime=20061116T1314Z]$cvs rtag -b another-new-thing lmi

remains appropriate, where two branches with distinct descriptive
names and different purposes are created the very same minute:
it might be uncommon for them to be that close together, but I
wouldn't rule it out.

> GC> We developed the calculation summary on a branch, then applied
> GC> discipline upon merging it. Perhaps similar projects should be
> GC> done the same way in the future. They'd be on project-specific
> GC> branches--distinct from the routine branches described above,
> GC> whose purpose is to keep the main trunk sacrosanct during formal
> GC> testing. Does that sound best?
> 
>  Yes, it sounds good for the relatively big projects, but I'd just like to
> use descriptive branch names for them.

Agreed.

> I hope it would still be possible to
> apply small patches (directly or after your review) to HEAD as creating a
> branch for each of them would be too much trouble and not worth it.

I strongly desire to keep HEAD releasable at all moments. I do
realize that other projects don't follow that discipline. Perhaps
our problem domain imposes unique circumstances. It's not quite
like writing life-critical avionics systems, but it's not like
most commercial systems, either. I'll try to explain that off the
list because the business rationale could involve discussing
information that one user company might consider proprietary, and
you already have a nondisclosure agreement with them.

> GC> - What should we do with obsolete branches?
[...]
>  I don't know if it's best but the common practice is to leave it alone.

Okay: that's what we'll do unless someone else has a
demonstrably better idea.