Re: SVN move

[Craig L Russell]

Hi Alan,

On Jul 25, 2008, at 3:31 PM, Alan D. Cabrera wrote:

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.

Craig

I don't agree with either of the above opinions. We don't restrict what people do with Apache code. I don't see anything wrong with publishing a release off the artifacts stored in Apache. It cannot be called "an Apache incubating release" but it can certainly be called JSecurity 0.9 whatever. Follow-on releases can similarly be built from code checked into the Apache repository. They just cannot be called "Apache anything". And if they're published in the jsecurity.org download area they can be maintained in the Apache repository. At some point, the community will have re-packaged stuff into the org.apache.jsecurity name space and built a release from the jsecurity trunk. At that time, they can build an apache incubating jsecurity release and try to get it out "the Apache Way". The incubator is concerned about the Apache brand. Not with pulling stuff out and calling it jsecurity.org. I'm copying general at incubator because this discussion needs some more eyes.

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

many people would notice that, and if they did, they'd probably be a

begin with.

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 developer of the project who was specifically looking for an old branch to

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.

Regards,
Alan

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.

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.


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:

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 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 imports/trunk to while changing package names (and licenses as
required).

It's not clear to me that we should have

see incubator/jsecurity/import/tags/0.90-beta2.


Just throwing out ideas to make it less opaque.

Craig

On Jul 25, 2008, at 12:09 PM, Les Hazlewood wrote:

The new top level trunk, tags, and branches would then be where we migrate incubator/jsecurity/tags/0.90-beta2 in the Apache repo. I'd much prefer to 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. 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.


an

trunk after that point as desired.

Would that be acceptable?

On Fri, Jul 25, 2008 at 2:49 PM, Craig L Russell <[EMAIL PROTECTED]

To achieve what you're talking about, I was hoping we could just create 'import' branch immediately after the migration and then start using the

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

never
done

know
if
this is possible?

On Fri, Jul 25, 2008 at 10:49 AM, Alan D. Cabrera <
[EMAIL PROTECTED]

wrote:

conflict for an svnadmin load of the migrated repo? I mean, I've an svnadmin load on anything other than a fresh repository - anyone

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!

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!

smime.p7s
Description: S/MIME cryptographic signature