Re: SVN move

[Craig L Russell]

Hi Les,

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.

+1

and still retain all revisions.

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

+1

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.

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

This is where I'd like to see the imported code go into a separate import directory.

And you would
only see that distinction in tags and branches.

Well, if you have tags/0.9.0 that has the org.jsecurity package name and tags/0.9.1 that has the org.apache.jsecurity package name; and the org.jsecurity wasn't an Apache release, and the org.apache.jsecurity was an Apache release, that's where I see an issue.

I just don't think that
many people would notice that, and if they did, they'd probably be a

begin with.


repository, that modification would bump up the revision to 1, and the

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

Craig

As Alan points out most Apache projects share the same repository, including *all* of the incubating projects. So we're not going to create our own repository. But I also recall that other projects have imported their entire history when entering the incubator, so it's something I'd leave for the experts in infrastructure to take care of.

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