Hi dev's,
I have cleaned up the wiki page dedicated to the GRASS cvs2svn
repository migration.
http://grass.gdf-hannover.de/wiki/Migration_from_CVS_to_SVN
Relevant text moved to the related discussion page.
Still space for last comments before migration will be done...
Martin
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
Martin Landa wrote:
I have cleaned up the wiki page dedicated to the GRASS cvs2svn
repository migration.http://grass.gdf-hannover.de/wiki/Migration_from_CVS_to_SVN
Relevant text moved to the related discussion page.
Still space for last comments before migration will be done...
I'm unclear on how further 6.x development is to be handled.
In the medium term, I would expect there to be futher development on
6.x culminating in a 6.4 release. This will need to occur on a
separate branch to 7.x. E.g.:
+----+----> 7.x-devel
|
+----+----+--------> 6.x-devel
| |
| +----> 6.4-release
|
+----> 6.3-release
The 6.x-devel and 6.3-release branches would be created immediately,
with 6.4-release created once 6.x-devel has accumulated changes which
cannot go into the 6.3.x releases.
The trunk would become 7.x-devel, and would quickly change to the
point that merging changes with 6.x-devel would become impractical.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2007/12/7, Glynn Clements <glynn@gclements.plus.com>:
I'm unclear on how further 6.x development is to be handled.
In the medium term, I would expect there to be futher development on
6.x culminating in a 6.4 release. This will need to occur on a
separate branch to 7.x. E.g.:+----+----> 7.x-devel
|
+----+----+--------> 6.x-devel
| |
| +----> 6.4-release
|
+----> 6.3-release
proposal...
+--+-----+-----> 7.x-devel (trunk)
| | |
| | +------> 6.4-release (branch) <--- should be created as
soon as possible
| | |
| | | backports (6.4 -> 6.3)
| | |
| +-------------> 6.3-release (branch)
Martin
The 6.x-devel and 6.3-release branches would be created immediately,
with 6.4-release created once 6.x-devel has accumulated changes which
cannot go into the 6.3.x releases.The trunk would become 7.x-devel, and would quickly change to the
point that merging changes with 6.x-devel would become impractical.--
Glynn Clements <glynn@gclements.plus.com>
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
Glynn Clements:
> I'm unclear on how further 6.x development is to be handled.
>
> In the medium term, I would expect there to be futher development on
> 6.x culminating in a 6.4 release. This will need to occur on a
> separate branch to 7.x. E.g.:
>
> +----+----> 7.x-devel
> |
> +----+----+--------> 6.x-devel
> | |
> | +----> 6.4-release
> |
> +----> 6.3-release
>
> The 6.x-devel and 6.3-release branches would be created immediately,
> with 6.4-release created once 6.x-devel has accumulated changes which
> cannot go into the 6.3.x releases.
>
> The trunk would become 7.x-devel, and would quickly change to the
> point that merging changes with 6.x-devel would become impractical.
Martin wrote:
proposal...
+--+-----+-----> 7.x-devel (trunk)
| | |
| | +------> 6.4-release (branch) <--- should be created [ASAP]
| | |
| | | backports (6.4 -> 6.3)
| | |
| +-------------> 6.3-release (branch)
I much prefer Glynn's proposal.
6.3.0 release branch is not meant to be a stable branch. We can fix bugs in it,
but if its purpose is to help get the MS Windows stuff tested, then that's a
lot of backporting from 6.x/HEAD when we get ready for 6.3.1. (or just make
6.3.1 a new branch from 6.x/HEAD). I consider it like 6.1.0, ie a dead-end
preview release.
6.4 requires a stable wxGUI, this isn't going to happen instantly. Porting
everything from 6.x/HEAD back into the 6.4 r.b. for months seems like a huge
waste of effort. Thus I think creating a 6.4 release branch ASAP is a mistake.
Let's do it when the code it ready.
There should be no need to port stuff back to 6.3 r.b. once we have a 6.4 r.b.
From then on we call the new preview releases 6.4beta1, etc. and forget 6.3.
We will need some strong discipline to put all new development into 7.x/HEAD
and backport interesting things to 6.x/HEAD; not the other way around.
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Hamish wrote:
> > I'm unclear on how further 6.x development is to be handled.
> >
> > In the medium term, I would expect there to be futher development on
> > 6.x culminating in a 6.4 release. This will need to occur on a
> > separate branch to 7.x. E.g.:
> >
> > +----+----> 7.x-devel
> > |
> > +----+----+--------> 6.x-devel
> > | |
> > | +----> 6.4-release
> > |
> > +----> 6.3-release
> >
> > The 6.x-devel and 6.3-release branches would be created immediately,
> > with 6.4-release created once 6.x-devel has accumulated changes which
> > cannot go into the 6.3.x releases.
> >
> > The trunk would become 7.x-devel, and would quickly change to the
> > point that merging changes with 6.x-devel would become impractical.Martin wrote:
> proposal...
>
> +--+-----+-----> 7.x-devel (trunk)
> | | |
> | | +------> 6.4-release (branch) <--- should be created [ASAP]
> | | |
> | | | backports (6.4 -> 6.3)
> | | |
> | +-------------> 6.3-release (branch)I much prefer Glynn's proposal.
6.3.0 release branch is not meant to be a stable branch. We can fix bugs in it,
but if its purpose is to help get the MS Windows stuff tested, then that's a
lot of backporting from 6.x/HEAD when we get ready for 6.3.1. (or just make
6.3.1 a new branch from 6.x/HEAD). I consider it like 6.1.0, ie a dead-end
preview release.
There may be some confusion with terminology. Currently, we have the
6.2-release branch (releasebranch_6_2), the 6.3-release branch
(releasebranch_6_3) and the trunk serving as 6.x-devel.
I'm proposing that we immediately create branches for 6.3-release and
6.x-devel, with a 6.4-release branch eventually being created as a
branch of 6.x-devel.
IOW, we need both 6.x and 7.x development branches (one of which would
be the trunk), in addition to any release branches. We don't need a
6.4 release branch yet.
6.4 requires a stable wxGUI, this isn't going to happen instantly. Porting
everything from 6.x/HEAD back into the 6.4 r.b. for months seems like a huge
waste of effort. Thus I think creating a 6.4 release branch ASAP is a mistake.
Let's do it when the code it ready.There should be no need to port stuff back to 6.3 r.b. once we have a 6.4 r.b.
>From then on we call the new preview releases 6.4beta1, etc. and forget 6.3.We will need some strong discipline to put all new development into 7.x/HEAD
and backport interesting things to 6.x/HEAD; not the other way around.
Backporting from 7.x to 6.x is likely to be somewhere between hard and
impossible, hence the need to maintain a 6.x-devel branch for the
medium term.
One of the first things which I want to do for 7.x is to globally
re-format all code to a common convention. That alone will cause
problems with merging.
--
Glynn Clements <glynn@gclements.plus.com>
Hi all,
2007/12/11, Glynn Clements <glynn@gclements.plus.com>:
> > > I'm unclear on how further 6.x development is to be handled.
> > >
> > > In the medium term, I would expect there to be futher development on
> > > 6.x culminating in a 6.4 release. This will need to occur on a
> > > separate branch to 7.x. E.g.:
> > >
> > > +----+----> 7.x-devel
> > > |
> > > +----+----+--------> 6.x-devel
> > > | |
> > > | +----> 6.4-release
> > > |
> > > +----> 6.3-release
> > >
> > > The 6.x-devel and 6.3-release branches would be created immediately,
> > > with 6.4-release created once 6.x-devel has accumulated changes which
> > > cannot go into the 6.3.x releases.
> > >
> > > The trunk would become 7.x-devel, and would quickly change to the
> > > point that merging changes with 6.x-devel would become impractical.
>
> Martin wrote:
> > proposal...
> >
> > +--+-----+-----> 7.x-devel (trunk)
> > | | |
> > | | +------> 6.4-release (branch) <--- should be created [ASAP]
> > | | |
> > | | | backports (6.4 -> 6.3)
> > | | |
> > | +-------------> 6.3-release (branch)
>
>
> I much prefer Glynn's proposal.
>
> 6.3.0 release branch is not meant to be a stable branch. We can fix bugs in it,
> but if its purpose is to help get the MS Windows stuff tested, then that's a
> lot of backporting from 6.x/HEAD when we get ready for 6.3.1. (or just make
> 6.3.1 a new branch from 6.x/HEAD). I consider it like 6.1.0, ie a dead-end
> preview release.There may be some confusion with terminology. Currently, we have the
6.2-release branch (releasebranch_6_2), the 6.3-release branch
(releasebranch_6_3) and the trunk serving as 6.x-devel.I'm proposing that we immediately create branches for 6.3-release and
? maybe I am wrong but branch for 6.3-release already exists (releasebranch_6_3)
6.x-devel, with a 6.4-release branch eventually being created as a
branch of 6.x-devel.
so it means (AFAIU)
+--+-----+-----> 7.x-devel (trunk)
| | |
| | +----------------------------+---------------------------->
6.x-devel (branch) <--- create *now*
| | | | |
| | | | | backports (6.x-devel -> 6.4)
| | | | |
| | | +-------------> 6.4-release
(releasebranch_6_4) <--- create later
| | | |
| | | backports (6.x-devel -> 6.3)
| | | |
| +-------------> 6.3-release (releasebranch_6_3)
IOW, we need both 6.x and 7.x development branches (one of which would
be the trunk), in addition to any release branches. We don't need a
6.4 release branch yet.
> 6.4 requires a stable wxGUI, this isn't going to happen instantly. Porting
> everything from 6.x/HEAD back into the 6.4 r.b. for months seems like a huge
> waste of effort. Thus I think creating a 6.4 release branch ASAP is a mistake.
> Let's do it when the code it ready.
I guess 7.x-devel should be trunk, I meant to create releasebranch_6_4
as 6.x-devel branch, it would make things more simple. The development
for 6.x would be in releasebranch_6_4 which would become last branch
of 6.x. Creating branch 6.x-devel right now and later creating
sub-branch releasebranch_6_4 is more clear, but a little bit more
complicated, see the diagrams above.
Martin
>
> There should be no need to port stuff back to 6.3 r.b. once we have a 6.4 r.b.
> >From then on we call the new preview releases 6.4beta1, etc. and forget 6.3.
>
>
> We will need some strong discipline to put all new development into 7.x/HEAD
> and backport interesting things to 6.x/HEAD; not the other way around.
>
Backporting from 7.x to 6.x is likely to be somewhere between hard and
impossible, hence the need to maintain a 6.x-devel branch for the
medium term.One of the first things which I want to do for 7.x is to globally
re-format all code to a common convention. That alone will cause
problems with merging.
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
Martin Landa wrote:
> There may be some confusion with terminology. Currently, we have the
> 6.2-release branch (releasebranch_6_2), the 6.3-release branch
> (releasebranch_6_3) and the trunk serving as 6.x-devel.
>
> I'm proposing that we immediately create branches for 6.3-release and? maybe I am wrong but branch for 6.3-release already exists (releasebranch_6_3)
> 6.x-devel, with a 6.4-release branch eventually being created as a
> branch of 6.x-devel.so it means (AFAIU)
+--+-----+-----> 7.x-devel (trunk)
| | |
| | +----------------------------+----------------------------> 6.x-devel (branch) <--- create *now*
| | | | |
| | | | | backports (6.x-devel -> 6.4)
| | | | |
| | | +-------------> 6.4-release (releasebranch_6_4) <--- create later
| | | |
| | | backports (6.x-devel -> 6.3)
| | | |
| +-------------> 6.3-release (releasebranch_6_3)
Ideally the 6.3-release branch would be a branch from 6.x-devel, as
that's how it's structured in CVS. But that may not be possible given
that it existed prior to the migration to SVN.
> IOW, we need both 6.x and 7.x development branches (one of which would
> be the trunk), in addition to any release branches. We don't need a
> 6.4 release branch yet.
> > 6.4 requires a stable wxGUI, this isn't going to happen instantly. Porting
> > everything from 6.x/HEAD back into the 6.4 r.b. for months seems like a huge
> > waste of effort. Thus I think creating a 6.4 release branch ASAP is a mistake.
> > Let's do it when the code it ready.I guess 7.x-devel should be trunk, I meant to create releasebranch_6_4
as 6.x-devel branch, it would make things more simple. The development
for 6.x would be in releasebranch_6_4 which would become last branch
of 6.x. Creating branch 6.x-devel right now and later creating
sub-branch releasebranch_6_4 is more clear, but a little bit more
complicated, see the diagrams above.
The general principle is that no development occurs on a release
branch.
Development occurs on a development branch (or the trunk). When it is
deemed time for a new series of releases, a the development branch is
forked to create a release branch, and a snapshot of the release
branch is created to form the first release candidate. Thereafter, the
only modifications to the release branch are made by merging specific
changes from the development branch to the release branch. The various
release candidates and releases are snapshots of the release branch.
This means that changes whose desirability is uncertain can be made to
the development branch. If they work out, they get merged onto the
release branch. If they don't work out, they simply don't get merged;
there is no need to explicitly back them out to obtain a stable
version for release.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn:
IOW, we need both 6.x and 7.x development branches (one of which would
be the trunk), in addition to any release branches. We don't need a
6.4 release branch yet.
Hamish:
> We will need some strong discipline to put all new development into
> 7.x/HEAD and backport interesting things to 6.x/HEAD; not the other
> way around.
Glynn:
Backporting from 7.x to 6.x is likely to be somewhere between hard and
impossible, hence the need to maintain a 6.x-devel branch for the
medium term.
If there is an open 6.x dev branch I am worried about duplication of
effort for things like new modules options, help pages, and the ongoing
SQL/vector hardening. ie things which are back-portable (probably by
hand), not major features which rely on the libs & data format to be a
certain way.
Which branch would "power user/developer" people use for their day to day
stuff while 7.x undergoes radical changes? (...self answering question...)
I guess avoiding fork incompatibilities matters most for the wxGUI
efforts which will be focused on getting that ready for 6.4. A solution
might be to only work on that in the 6.x dev branch until the 6.4 release
branch is created. At that moment non-bug fixing GUI devel would be
stopped in the 6.x line and the wxGUI is ported in its entirety to the
7.x dev branch (ie trunk).
that doesn't give much GUI-wise to play with for 7.x devel, but I
suppose it would be possible to throw together a simple & disposable
prototype GUI until the wxGUI moves into 7.x land, and initial 7.x devels
will be command line oriented people anyway.
</speculating>
Hamish
Glynn Clements wrote:
Ideally the 6.3-release branch would be a branch from 6.x-devel, as
that's how it's structured in CVS. But that may not be possible given
that it existed prior to the migration to SVN.
I wonder if we should sort of re-do the 6.3-release branch. I am not
aware of incompatible changes within HEAD yet. Maybe it is better
to branch off again (say, to bulk merge from HEAD/trunk into the
existing branch) to catch recent fixes for 6.3.0.
Glynn Clements wrote:
The general principle is that no development occurs on a release
branch.
The general scope should be to fade out 6.x *development* (keep maintenance)
and focus on GRASS 7. Given our limited resources, I don't see an
alternative.
We all would like to make so many major changes to GRASS that
this cannot happen in the 6.x line but in 7.x only. So let's start!
Markus
--
View this message in context: http://www.nabble.com/GRASS-CVS-to-SVN-migration%3A-repository-structure-tp14189273p14360174.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
On Sun, 16 Dec 2007, Markus Neteler wrote:
Glynn Clements wrote:
Ideally the 6.3-release branch would be a branch from 6.x-devel, as
that's how it's structured in CVS. But that may not be possible given
that it existed prior to the migration to SVN.I wonder if we should sort of re-do the 6.3-release branch. I am not
aware of incompatible changes within HEAD yet. Maybe it is better
to branch off again (say, to bulk merge from HEAD/trunk into the
existing branch) to catch recent fixes for 6.3.0.
If such a bulk merge from the HEAD to the (as it currently is) 6.3 release branch could be done, I think that would be a good plan and the 6.3-release branch could be renamed to e.g. 6.x-devel and development go on there---then the 7.x big changes could start on the HEAD.
Or the 6.3-release branch could be dumped (see below) and 6.x-devel branched off the HEAD, leaving it free to be in effect "7.x-devel".
My main concern/doubt is that I don't see why 6.3 needs to have a release branch at all at this stage. I thought release branches were only for stable releases where the functionality needs to be frozen. As 6.3.0 is going to be a development (not stable) release, it makes sense to me for it to be a direct snapshot off the development branch or HEAD - similar to the way the 5.0.0pre releases were done in the dim and distant past. If we decide that 6.3.1 is going to be a stable release, or we call it 6.4.0, or whenever, *that* is when we should be creating a release branch, IMHO.
Paul
Paul Kelly wrote:
>> Ideally the 6.3-release branch would be a branch from 6.x-devel, as
>> that's how it's structured in CVS. But that may not be possible given
>> that it existed prior to the migration to SVN.
>
> I wonder if we should sort of re-do the 6.3-release branch. I am not
> aware of incompatible changes within HEAD yet. Maybe it is better
> to branch off again (say, to bulk merge from HEAD/trunk into the
> existing branch) to catch recent fixes for 6.3.0.If such a bulk merge from the HEAD to the (as it currently is) 6.3 release
branch could be done, I think that would be a good plan and the
6.3-release branch could be renamed to e.g. 6.x-devel and development go
on there---then the 7.x big changes could start on the HEAD.Or the 6.3-release branch could be dumped (see below) and 6.x-devel
branched off the HEAD, leaving it free to be in effect "7.x-devel".My main concern/doubt is that I don't see why 6.3 needs to have a release
branch at all at this stage. I thought release branches were only for
stable releases where the functionality needs to be frozen. As 6.3.0 is
going to be a development (not stable) release, it makes sense to me for
it to be a direct snapshot off the development branch or HEAD - similar to
the way the 5.0.0pre releases were done in the dim and distant past. If we
decide that 6.3.1 is going to be a stable release, or we call it 6.4.0, or
whenever, *that* is when we should be creating a release branch, IMHO.
The main problem with making releases from the trunk is that if
someone commits a change which ends up taking some time to get right,
we either have to postpone releases or revert the change. If we have a
separate branch, we can simply avoid merging that particular change.
--
Glynn Clements <glynn@gclements.plus.com>