incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <>
Subject Re: SVN move
Date Sat, 26 Jul 2008 15:36:55 GMT
This brings up a follow-up question - when Wicket graduated to a TLP, were
you able to retain the history while working in the Incubator when you moved
to an SVN repo of your own?

On Sat, Jul 26, 2008 at 11:22 AM, Les Hazlewood <> wrote:

> On Sat, Jul 26, 2008 at 5:47 AM, Martijn Dashorst <
>> wrote:
>> On Sat, Jul 26, 2008 at 10:20 AM, Bertrand Delacretaz
>> <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message