Some things to consider in this discussion:
- The 0.9.0 release cannot be performed off of the copy in ASF
- The 0.9.0 or earlier releases cannot be supported off of the copy in
ASF
Maybe that's what everyone is thinking. I just want to make sure that
it's clear.
On Jul 25, 2008, at 1:07 PM, Les Hazlewood wrote:
I'd like to keep all history, so we don't lose anything along the
way. You
never know when you might need to go look back at something for
comparison.
Plus since SVN atomically increments version numbers across trunk,
branches
and tags collectively, I don't think you can select just one or the
other
and still retain all revisions.
Yeah, I'm all for importing it with the full history as it's currently
organized at SourceForge. I just think that we shouldn't keep
anything other than trunk *after* the import for the above reasons.
If someone really wants that stuff then could dig it up since it's in
SVN.
There's a convention here at ASF that anything lying around in SVN
should be supported.
I personally don't think its a big deal just to have a 1:1 move and
keep
everything the way it is - just my opinion. After 0.9.0 final is
released
and we make the switch to org.apache.jsecurity.*, I think it would be
self-evident that if you saw something that didn't match that package
structure, that it is code that came in before the import. And you
would
only see that distinction in tags and branches. I just don't think
that
many people would notice that, and if they did, they'd probably be a
developer of the project who was specifically looking for an old
branch to
begin with.
Yeah, but given the above points we really can't have that stuff lying
around, imo.
But this may all be a moot point. The 'svnsync' command (outlined
in the
jira issue), requires the very first operation to be revision 0.
The import
must start on revision 1. If we were to create an import directory
in the
repository, that modification would bump up the revision to 1, and the
actual code import wouldn't be able to start on revision 1. I don't
think
SVN sync allows this - it is a tool for an exact copy only as far as
I know.
Well then I know that this will be impossible then because I know that
ASF, in its infinite wisdumb, put all projects in a single Subversion
database. So it will be impossible for the very first operation on
our project to be revision 0.
Regards,
Alan
On Fri, Jul 25, 2008 at 3:43 PM, Alan D. Cabrera
<[EMAIL PROTECTED]>wrote:
Ahh, ok. My idea was to drop the imported branches and tags and
just keep
trunk. We would tag it as "import". Then re-org everything inside
trunk
with the goal of making a 1.0 release that would be acceptable to the
Incubator.
I guess I just assumed that the history in trunk would be good
enough. If
someone wanted to look at the old branches and tags it would be
simple
enough to get copies of them using the svn update command.
Just a tought.
Regards,
Alan
On Jul 25, 2008, at 12:32 PM, Craig L Russell wrote:
All the code being imported has the org.jsecurity package name,
including
the trunk, tags, and branches, I think it would be less confusing
to put
trunk, tags, and branches under a new top level directory called
import.
The new top level trunk, tags, and branches would then be where we
migrate
the imports/trunk to while changing package names (and licenses as
required).
It's not clear to me that we should have
incubator/jsecurity/tags/0.90-beta2 in the Apache repo. I'd much
prefer to
see incubator/jsecurity/import/tags/0.90-beta2.
My thoughts on this process are (obviously) evolving. I just want
to make
it clear to anyone browsing the Apache repository that there is
legacy code
being imported and there is code that will become the Apache
distribution.
Just throwing out ideas to make it less opaque.
Craig
On Jul 25, 2008, at 12:09 PM, Les Hazlewood wrote:
Actually I don't think that is possible - the existing repo
already has
'trunk', 'branches' and 'tags' that need to be preserved in the
same
location.
To achieve what you're talking about, I was hoping we could just
create
an
'import' branch immediately after the migration and then start
using the
trunk after that point as desired.
Would that be acceptable?
On Fri, Jul 25, 2008 at 2:49 PM, Craig L Russell <[EMAIL PROTECTED]
wrote:
Is it too late to suggest that the top level directory for the
imported
code be "import" and not "trunk"? Using the import directory
would allow
development to continue (in import) and put all of the future
Apache
deliverables into trunk.
Craig
On Jul 25, 2008, at 8:43 AM, Les Hazlewood wrote:
Ok, I'll let the infrastructure folks know they can blast away the
existing
one when performing the load.
Thanks,
Les
On Fri, Jul 25, 2008 at 11:04 AM, Alan D. Cabrera <
[EMAIL PROTECTED]
wrote:
Crickey, you may be right. It's simple enough to recreate
those few
files.
Regards,
ALan
On Jul 25, 2008, at 7:58 AM, Les Hazlewood wrote:
I want to do it today or tomorrow. Sunday at the latest for
sure.
Just out of curiosity - I see the new SVN is being used.
Won't that
cause
a
conflict for an svnadmin load of the migrated repo? I mean,
I've
never
done
an svnadmin load on anything other than a fresh repository -
anyone
know
if
this is possible?
On Fri, Jul 25, 2008 at 10:49 AM, Alan D. Cabrera <
[EMAIL PROTECTED]
wrote:
Les, have you been able to make your SVN dump yet? When can we
expect
this?
Regards,
Alan
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
