commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juancarlo AƱez <>
Subject Re: [vote] Move JRCS out of Jakarta
Date Mon, 29 Sep 2003 14:46:45 GMT
Hello Serge,

> You have shell access to the ASF CVS server, so you can already do
> backups of the repository.

I didn't know that. I checked, and yes, I can go in.

> I suppose you could edit history files, but I really would
> recommend against it.

I've done repository manipulation (moving files around, basically) before
for what I think are valid reasons. I always do a full backup first.

In this case, the reason for wanting to manipulate the repository is because
I think that the differencing engine should be split from JRCS. That's
because more people have interest in the engine than in archive
manipulation, and bundling the two libraries makes the engine less visible.

> Sandbox is where things go by default, but I agree that it should get
> promoted out of sandbox from my use of it.  This is an opposite
> direction though of moving JRCS off. :)  are you softening to the idea
> of keeping it here?

The diff engine is ready for prime-time, as it has been used extensively by
several different people, so it could go into the commons proper.

The archive manipulation is stable, but it's incomplete (there's no
knowledge about binary files in it), and, though reading of archives works
fine, I wont't use the tool on my live repositories until someone writes a
serious set of tests for that (someone already did this, but he couldn't
publish the test suite because it worked on private files).

After moving the project elsewhere, my plan was to:

* Split the diff engine from archive manipulation

* Find a name for the diff engine (JDiff is overloaded) [perjaps

* Give each subproject its own page and repository.

Can that be done here without too much delay or red tape?

After that, I'm planning to make the following changes:

* Reimplement Revision.toString() and Revision.toRCSString() using the
already available visitor pattern, so they serve as examples for others to
implement their own Revision->plain-text conversions.

* Perhaps reimplement the diff engine in terms of java.util.List to give
some hope to folks who want to apply the Myers algorithm to really large
input sequences.

* Add support for binaries (-kb) to jrcs.

* Add a user guide to both subprojects.

The only thing that should not happen is that the project is made visible
here and somewhere else at the same time.

I have already been offered hosting for the project elsewhere. I'm wating
for this discussion to arrive to a conclusion before making a move. The
voting, as I remember, was +2 -1. My own criteria is that uless at least a
couple of committers voluntier to do project maintenance (especially the
admin stuff), I should think that there's not much interest for the project
here, that Jakarta is in fact not endorsing it, and that it makes most sense
to move the project out.


View raw message