Re: SVN move

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Les Hazlewood
Administrator
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 <[hidden email]>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 <[hidden email]
>> >wrote:
>>
>>  Les, have you been able to make your SVN dump yet?  When can we expect
>>> this?
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Les Hazlewood
Administrator
It turns out 'svnsync' is the appropriate way to do this.  I'll open an
issue ticket for them now.  I'm disabling SVN commit access to the current
repo (read access still allowed of course).

On Fri, Jul 25, 2008 at 11:43 AM, Les Hazlewood <[hidden email]> 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 <[hidden email]>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 <[hidden email]
>>> >wrote:
>>>
>>>  Les, have you been able to make your SVN dump yet?  When can we expect
>>>> this?
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>>
>>>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

papajdo
In reply to this post by Les Hazlewood
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 <[hidden email]
> >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 <[hidden email]
>>>> 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:[hidden email]
P.S. A good JDO? O, Gasp!


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Les Hazlewood
Administrator
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 <[hidden email]>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 <[hidden email]
>> >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 <[hidden email]
>>>>
>>>>> 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:[hidden email]
> P.S. A good JDO? O, Gasp!
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Alan D. Cabrera
Yeah, we should be able to move things around once it's imported.  I  
imagine that it would initially get tagged as "import" with work  
continuing on in trunk.


Regards,
Alan

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 <[hidden email]
> >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 <[hidden email]
>>>> 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 <[hidden email]
>>>>>
>>>>>> 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:[hidden email]
>> P.S. A good JDO? O, Gasp!
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

papajdo
In reply to this post by Les Hazlewood
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 <[hidden email]
> >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 <[hidden email]
>>>> 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 <[hidden email]
>>>>>
>>>>>> 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:[hidden email]
>> 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:[hidden email]
P.S. A good JDO? O, Gasp!


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Alan D. Cabrera
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 <[hidden email]
>> >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 <[hidden email]
>>>>> 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 <[hidden email]
>>>>>>
>>>>>>> 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:[hidden email]
>>> 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:[hidden email]
> P.S. A good JDO? O, Gasp!
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Les Hazlewood
Administrator
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.

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.

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.

On Fri, Jul 25, 2008 at 3:43 PM, Alan D. Cabrera <[hidden email]>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 <[hidden email]
>>> >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 <
>>>>> [hidden email]
>>>>>
>>>>>> 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 <
>>>>>>> [hidden email]
>>>>>>>
>>>>>>>  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:[hidden email]
>>>> 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:[hidden email]
>> P.S. A good JDO? O, Gasp!
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Alan D. Cabrera
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  
> <[hidden email]>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 <[hidden email]
>>>>> 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 <
>>>>>> [hidden email]
>>>>>>
>>>>>>> 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 <
>>>>>>>> [hidden email]
>>>>>>>>
>>>>>>>> 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:[hidden email]
>>>>> 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:[hidden email]
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

papajdo
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.

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.

Craig

>
>
> 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 <[hidden email]
>> >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 <[hidden email]
>>>>>> 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 <
>>>>>>> [hidden email]
>>>>>>>
>>>>>>>> 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 <
>>>>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>>> 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:[hidden email]
>>>>>> 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:[hidden email]
>>>> 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:[hidden email]
P.S. A good JDO? O, Gasp!


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Alan D. Cabrera

On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:

> 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.
>
> 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.

I'm not so sure about this.  Is there a precedent for this?

> 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.

Thanks.  I am very interested in what others have to say about this.


Regards,
Alan

>
>
> Craig
>>
>>
>> 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 <[hidden email]
>>> >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 <[hidden email]
>>>>>>> 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 <
>>>>>>>> [hidden email]
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>>> [hidden email]
>>>>>>>>>>
>>>>>>>>>> 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:[hidden email]
>>>>>>> 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:[hidden email]
>>>>> 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:[hidden email]
> P.S. A good JDO? O, Gasp!
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

William A. Rowe Jr.
Alan D. Cabrera wrote:

>
> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>
>> 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.
>>
>> 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.
>
> I'm not so sure about this.  Is there a precedent for this?

Of course.  Understand that it's not Apache Foo x.x.x, and that the ASF
doesn't publish or take account for the contents of such an external
package.

Which effectively means the committer (or their employer if they are
acting on the behalf of such) is assuming all responsibilities for such
a package.  This is usually not the sort of personal responsibility an
individual desires, so it would probably make more sense to resolve the
issues at the project and vote on an ASF release.

The act of a tag-tar-vote-release at the ASF is an act of the foundation
(as long as the RM/PMC follows the whole process) so it is a shield, of
sorts.  If the RM and project acts in good faith, the ASF backs the
release and is a much more public face to settle any later disputes.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Alan D. Cabrera

On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:

> Alan D. Cabrera wrote:
>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>> 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.
>>>
>>> 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.
>> I'm not so sure about this.  Is there a precedent for this?
>
> Of course.

Can you provide one example?  Just curious.

> Understand that it's not Apache Foo x.x.x, and that the ASF
> doesn't publish or take account for the contents of such an external
> package.
>
> Which effectively means the committer (or their employer if they are
> acting on the behalf of such) is assuming all responsibilities for  
> such
> a package.  This is usually not the sort of personal responsibility an
> individual desires, so it would probably make more sense to resolve  
> the
> issues at the project and vote on an ASF release.
>
> The act of a tag-tar-vote-release at the ASF is an act of the  
> foundation
> (as long as the RM/PMC follows the whole process) so it is a shield,  
> of
> sorts.  If the RM and project acts in good faith, the ASF backs the
> release and is a much more public face to settle any later disputes.

Not that I believe that it will happen in the case of the JSecurity  
project but, does this not mean that the "original" project can  
continue for a potentially long time to develop their own releases off  
of the ASF repo?  That's ok?

What if the license for those releases was incompatible w/ AL2.0? They  
could continue to make releases on their own?

What if there was absolutely no community involvement for those  
branches and their releases?

What happens to that code base when the project graduates?  I imagine  
that it would probably have to stay.

Again, I don't think this will occur for JSecurity but I am just  
trying to get my head in the same place a s you guys.



Regards,
Alan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

William A. Rowe Jr.
Alan D. Cabrera wrote:

>
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>
>> Alan D. Cabrera wrote:
>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>> 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.
>>> I'm not so sure about this.  Is there a precedent for this?
>> Of course.
>
> Can you provide one example?  Just curious.

Try any project or product that integrates ASF code.  The AL's permitted
applications are clear.

>> Understand that it's not Apache Foo x.x.x, and that the ASF
>> doesn't publish or take account for the contents of such an external
>> package.
>>
>> Which effectively means the committer (or their employer if they are
>> acting on the behalf of such) is assuming all responsibilities for such
>> a package.  This is usually not the sort of personal responsibility an
>> individual desires, so it would probably make more sense to resolve the
>> issues at the project and vote on an ASF release.
>>
>> The act of a tag-tar-vote-release at the ASF is an act of the foundation
>> (as long as the RM/PMC follows the whole process) so it is a shield, of
>> sorts.  If the RM and project acts in good faith, the ASF backs the
>> release and is a much more public face to settle any later disputes.
>
> Not that I believe that it will happen in the case of the JSecurity
> project but, does this not mean that the "original" project can continue
> for a potentially long time to develop their own releases off of the ASF
> repo?  That's ok?

"off the asf".  I presume you aren't talking about ASF tags.  But there's
no reason someone can't use the ASF code under the AL at any given point
in time.

> What if the license for those releases was incompatible w/ AL2.0? They
> could continue to make releases on their own?

The license is AL.  It can be packaged in any way that is compatible with
the AL.  Whatever license, it must not violate the AL.

> What if there was absolutely no community involvement for those branches
> and their releases?

What release?  We aren't talking about the ASF.

> What happens to that code base when the project graduates?  I imagine
> that it would probably have to stay.

Huh?  Which code base, where, and why would you imagine that?

There's ASF code.  There is other people's code.  We care about the code
and releases from the ASF.  How others use it is their prerogative and
liability.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

papajdo
In reply to this post by Les Hazlewood
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

>
> 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.

+1
>
>
> 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.

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

Craig

>
>
> On Fri, Jul 25, 2008 at 3:43 PM, Alan D. Cabrera  
> <[hidden email]>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 <[hidden email]
>>>>> 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 <
>>>>>> [hidden email]
>>>>>>
>>>>>>> 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 <
>>>>>>>> [hidden email]
>>>>>>>>
>>>>>>>> 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:[hidden email]
>>>>> 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:[hidden email]
>>> 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:[hidden email]
P.S. A good JDO? O, Gasp!


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Emmanuel Lécharny
In reply to this post by Les Hazlewood
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.
>  
+1

<snip/>
> 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.
That won't be possible here. We already are at rev 680 000 ...

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Bertrand Delacretaz
In reply to this post by Alan D. Cabrera
On Sat, Jul 26, 2008 at 6:04 AM, Alan D. Cabrera <[hidden email]> wrote:

>
> On Jul 25, 2008, at 8:50 PM, William A. Rowe, Jr. wrote:
>
>> Alan D. Cabrera wrote:
>>>
>>> On Jul 25, 2008, at 7:38 PM, Craig L Russell wrote:
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>
>>> I'm not so sure about this.  Is there a precedent for this?
>>
>> Of course.
>
> Can you provide one example?  Just curious....

While it was incubating, Wicket did a few non-ASF releases on their
old project site, to minimize disruption for their existing users
while they were repackaging and cleaning up for an ASF release.

I haven't followed all of this discussion, but IIUC that's a similar situation.

-Bertrand
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Martijn Dashorst
On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
<[hidden email]> wrote:
>> Can you provide one example?  Just curious....
>
> While it was incubating, Wicket did a few non-ASF releases on their
> old project site, to minimize disruption for their existing users
> while they were repackaging and cleaning up for an ASF release.

And even after we had graduated. Wicket 1.2.7 (the final maintenance
release for the 1.2 branch) was created in last March. We didn't use
the Apache mirroring system and put a disclaimer in it that the
release was non-Apache. [1]

This is a service we provide for our users that were with us before we
moved to apache and are counting on us to provide support on their
production systems. However, since we are a volunteer effort with
limited resources, we have discontinued to support the 1.2 branch
(though we will act on security issues) and now focus on Apache
software :).

> I haven't followed all of this discussion, but IIUC that's a similar situation.

Yep, and it really is a problem IMO when incoming *open source*
projects have to ditch their collected history. If we care about code
provenance, having the full history available is best.

Martijn

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: SVN move

Noel J. Bergman
In reply to this post by Bertrand Delacretaz
Bertrand Delacretaz wrote:

> While it was incubating, Wicket did a few non-ASF releases on their
> old project site, to minimize disruption for their existing users
> while they were repackaging and cleaning up for an ASF release.

If I recall correctly, the first project that had to address this seriously was Roller.  Dave Johnson and Justin Erenkrantz discussed issues in detail.

        --- Noel


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SVN move

Les Hazlewood
Administrator
In reply to this post by Martijn Dashorst
On Sat, Jul 26, 2008 at 5:47 AM, Martijn Dashorst <
[hidden email]> wrote:

> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
> <[hidden email]> wrote:
> >> Can you provide one example?  Just curious....
> >
> > While it was incubating, Wicket did a few non-ASF releases on their
> > old project site, to minimize disruption for their existing users
> > while they were repackaging and cleaning up for an ASF release.
>
> And even after we had graduated. Wicket 1.2.7 (the final maintenance
> release for the 1.2 branch) was created in last March. We didn't use
> the Apache mirroring system and put a disclaimer in it that the
> release was non-Apache. [1]


In my opinion, this is more important than anything else.  If we're going to
import our code into ASF SVN, we must still be able to make edits to that
code with the intention of releasing those edits later outside of the ASF to
our existing community.

To bring others up to speed, this is what we're looking at right now:

The JSecurity team is trying to release 0.9.0 RC1 to our existing community,
with no ties to the ASF.  After that is out, it isn't unlikely that a few
more changes will need to occur before 0.9.0 Final.  (There might even be an
RC2, but I hope not - we'll see).  After 0.9.0 final is out, only then do I
think would we want to call any of our releases an ASF release and go
through the Incubator release approval process.  Prior to that I have no
problem not mentioning ASF anywhere.

In other words, we would keep doing things exactly as we have for the last
three years, its just we happen to be using ASF SVN hosting instead of
SourceForge SVN hosting - that would be the only difference.

The reason why this is critiical is if any source code changes go in to say,
an 0.9.0 brach, they have to make their way into trunk at the same time -
branch merging and all, etc.  That would be a nightmare if we have to make
these changes manually to two different repositories.  If that is forced
upon us, I would ask the previous JSecurity dev team to wait to do the code
import into ASF until after that time.

But I don't like this option - it doesn't attract other ASF developers
because they don't have ASF access to the source code - they'd have to join
the SF project until the time when the team says they want to do their first
ASF release.  Not ideal IMO.

I don't see the early-import into ASF SVN as a problem though:  to me at
least, this is one of the things the incubation process helps to resolve -
there is nothing IMO wrong with ASF SVN hosting source code for an existing
oommunity under the knowledge that it will be actively converted to the ASF
community in the process.  That's part of migration, which to me, is a key
point of incubation for projects with a previous history.


Yep, and it really is a problem IMO when incoming *open source*
> projects have to ditch their collected history. If we care about code
> provenance, having the full history available is best.


As far as I'm concerned, ditching history is not an option at all.  We need
to always be able to compare previous code, maybe resurrect things that were
deleted, etc.  I'd hate to lose that capability.

Martjin,  when you guys migrated your source code for Wicket, how did you
retain history when it was imported into the Incubator SVN?  Did you use
'svnadmin dump' and then load it into the Incubator repository via 'svnadmin
load'?  Or did you use svnsync? (this is all assuming that your previous
repo was already SVN...)

Cheers,

Les
123
Loading...