harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [classlib][pack200] Development has stalled :-(
Date Thu, 14 Dec 2006 16:56:41 GMT
Alex,

Alex Blewitt wrote:
> ... it will likely be easier for me to
> develop code against a repository which I have write access and an
> structure it appropriately. 

This is exactly what you can achieve by using some other version
control system, besides SVN.

You can have a local repository with write access and ability
to structure it in any way you want without giving up on the ability
to submit patches to Harmony project.

> Since it too will be licensed under AL,
> Harmony can then chose to take advantage of it or someone else can
> continue working on the codebase so far.

This looks like you are suggesting to continue your development as a separate
project. While I think this is possible, it would imply that you have
to handle some tedious tasks like finding hosting, creating mailing lists
and other infrastructure.

I think you can save your time by continuing participation in Harmony project.

Concerning the proposed reorganization, I haven't seen any patches / svn
scripts for that. It doesn't look like that anyone is against moving pack200
code into separate module, it is just that noone had enough motivation
to do the actual work, i.e. prepare svn script for moving files, make sure
the build scripts and tests work etc.

I believe if you come up with concrete patches and svn scripts, it will not be
hard to get agreement on committing them.

I've tried to reproduce your workflow with Git [1],
which is the local version control system I use myself.
I think the following command sequence captures the way how you
can exercise full control over your local repository,
while retaining the ability to submit patches to Harmony easily.

	svn co https://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk
	cd trunk
	git init-db
	echo '.svn' >> .git/info/exclude
	git add .
	git commit -m "imported svn sources"	

Now we can create a local copy for development

	cd ..
	git clone trunk work
	cd work

And pretend we do some development, along with necessary reorganizations

	mkdir -p modules/pack200/src/main/java/org/apache/harmony/pack200
	mv modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200/*
modules/pack200/src/main/java/org/apache/harmony/pack200
	git rm modules/archive/src/main/java/org/apache/harmony/archive/internal/pack200
	git add modules/pack200/src/main/java/org/apache/harmony/pack200
	echo '/* new development */' >
modules/pack200/src/main/java/org/apache/harmony/pack200/NewDevelopment.java
	git add
modules/pack200/src/main/java/org/apache/harmony/pack200/NewDevelopment.java
	echo '/* new development */' >>
modules/pack200/src/main/java/org/apache/harmony/pack200/BHSDCodec.java

See what we changed and commit changes

	git status
	git commit -a -m "reorganization and new development"

(We could do reorganizations and development in separate steps, committing as
we want)

Then, the resulting patch could be obtained by diffing with original contents
of the imported branch

	git diff -M origin	# -M to detect moved files

As is often requested by Harmony committers, the reorganization script could be
 easily produced from the patch with detected renames:

	git diff -M origin | perl -ne 's/^rename from (.*)$/svn mv $1 \\/ && print;
s/^rename to (.*)$/$1/ && print "  $_\n";'

The local workspace can be brought up-to-date with developments in SVN in two
steps: update the tracking workspace first, and then pull the changes from
tracking repository into working repository.

	cd ../trunk
	svn update
	git add .	# to make sure we don't miss added files
	git commit -a -m "svn sync"
	cd ../work
	git pull

After the working copy was updated, the updated patch can be generated with the
same command as before. If some of the workspace changes have been committed
into SVN, then they will automatically disappear from this difference.

	git diff -M origin	

Possible improvements of this workflow are possible, for example, using Tailor
[2] for importing history from SVN into git repository. Please let me know
if you would like to hear more details on that.

[1] http://git.or.cz
[2] http://www.darcs.net/DarcsWiki/Tailor


Mime
View raw message