Rivet development branches

[Massimo Manghi <ma...@unipr.it>]

Lately I've been spending most of the time I dedicate to Rivet working 
on the debianization of it. I'm being helped in the process by Sven 
Hoexter, Debian Maintainer (thanks Sven), who checked thoroughly every 
commit I did and has been very helpful.

Most if not all the commits I did were restricted to the contents of the 
debian/ directory, so I thought as a good thing not to add noise on the 
list for commits related neither to the module source nor the Tcl 
library (noticeable exceptions are the new distclean targets added to 
the Makefile.am and doc/Makefile.am).

Last week I managed to build 2 packages able to pass the basic Debian 
test scripts and uploaded them to mentors.debian.net. (To the Debian 
users: look up libapache2-mod-rivet if you want to rebuild the packages 
on your own). I hoped those commits were the last ones but today Sven 
found more incomplete files and wrong information in Rivet that would 
set up the packages for an unavoidable rejection by the ftp master (in 
the end the business will gain to me a Master in Debian Sciences... :-< )

I realize now that the whole thing is taking much longer than I hoped 
and I'm growing uneasy to do more commits to trunk silently. Virtually 
I'm locking 'trunk' preventing Damon from adding the new stuff he had 
intention to put in Rivet that would require tcl 8.5.

Moreover, while I'm still able to merge the changes into the 2_0 keeping 
it aligned to trunk, it has become a senseless way to work and probably 
it's time to question the existence of a 2_0 branch as a working space 
to be kept open indefinitely with the only purpose to do more 2.0.x releases

My proposal

1) Use the 2_0 branch for the debian development. I will test the debian 
build process using tarballs exported from a working copy of 2_0 and 
commit the changes to this branch once the package created has been 
accepted by Debian.

2) When the PPD (Picky People of Debian) will accept the package the new 
2.0.2 will be copied out of 2_0 and this branch abandoned as a branch 
from which create tagged releases. The branch will then be reintegrated 
into 'trunk' and declared dead.

3) In case a 2.0.3 release (tcl8.4 compatible) will be created copying 
it from tags/2.0.2.

3) If Damon wants to throw in the changes that will break tcl8.4 
compatibility he can do it in trunk at will.

I don't know what the 1_0 branch was meant for but I consider that 
development branch as abandoned.

Sorry for the long message.

  -- Massimo


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org

Re: Rivet development branches

[Massimo Manghi <ma...@unipr.it>]

On 10/25/2010 11:29 AM, David Welton wrote:
> That sounds pretty good to me.  Not sure why you'd abandon the 2_0
> branch though.... just keep it for future 2.0.x releases, no?
>
>    
in subversion 1.5 a 'svn merge --reintegrate ...' destroys the coherence 
of the branch that becomes unusable for further work. My svn is svn 1.6, 
but i'm not totally sure they got around this limit in this version.

Reconstructing a 2_0 branch can be done any time because deleted files 
are never actually removed from the repository and reviving a branch is 
tantamount to restore a set of deleted files.


   -- Massimo


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org

Re: Rivet development branches

[David Welton <da...@dedasys.com>]

> My proposal
>
> 1) Use the 2_0 branch for the debian development. I will test the debian
> build process using tarballs exported from a working copy of 2_0 and commit
> the changes to this branch once the package created has been accepted by
> Debian.
>
> 2) When the PPD (Picky People of Debian) will accept the package the new
> 2.0.2 will be copied out of 2_0 and this branch abandoned as a branch from
> which create tagged releases. The branch will then be reintegrated into
> 'trunk' and declared dead.
>
> 3) In case a 2.0.3 release (tcl8.4 compatible) will be created copying it
> from tags/2.0.2.
>
> 3) If Damon wants to throw in the changes that will break tcl8.4
> compatibility he can do it in trunk at will.

That sounds pretty good to me.  Not sure why you'd abandon the 2_0
branch though.... just keep it for future 2.0.x releases, no?

-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org