logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <psm...@aconex.com>
Subject Re: SVN Migration?
Date Wed, 20 Jul 2005 21:53:36 GMT
I can't see anything wrong with Curt's plan.  +1

 From what I've been following, transitioning to SVN recently has  
been pretty smooth, so we'd be riding on the work done by previous  
efforts.

cheers,

Paul Smith

On 21/07/2005, at 7:22 AM, Curt Arnold wrote:

>
> On Jul 20, 2005, at 3:01 PM, Niclas Hedhman wrote:
>
>>
>> A simple request that the "logging-" prefix is dropped is no big  
>> deal, and
>> accommodated without any reflections.
>>
>>
>
> The XML project dropped the xml- (http://xml.apache.org/svn.html#Web 
> +Access+to+the+Repository) and I think that we should do likewise.
>
> After the conversion, we'd have something like:
>
> /logging
>     /chainsaw
>        /trunk
>        /tags
>        /branches
>     /log4cxx
>        /trunk
>        /tags
>        /branches
>     /log4j
>        /trunk
>        /tags
>        /branches
>     /log4net
>        /trunk
>        /tags
>        /branches
>     /site
>        /trunk
>        /tags
>        /branches
>
> After the repo is established, then I'd suggest establishing a  
> logging/sandbox and find a new home for logging-log4j/contribs  
> (which could be the sandbox)
>
>
> From the Subversion book (http://svnbook.red-bean.com/en/1.1/svn- 
> book.html#svn-ch-5-sect-6.1)
>
>> There are benefits to using a single repository for multiple  
>> projects, most obviously the lack of duplicated maintenance. A  
>> single repository means that there is one set of hook scripts, one  
>> thing to routinely backup, one thing to dump and load if  
>> Subversion releases an incompatible new version, and so on. Also,  
>> you can move data between projects easily, and without losing any  
>> historical versioning information.
>>
>> The downside of using a single repository is that different  
>> projects may have different commit mailing lists or different  
>> authentication and authorization requirements. Also, remember that  
>> Subversion uses repository-global revision numbers. Some folks  
>> don't like the fact that even though no changes have been made to  
>> their project lately, the youngest revision number for the  
>> repository keeps climbing because other projects are actively  
>> adding new revisions.
>>
> In our current CVS setup, each sub-project (chainsaw, log4cxx,  
> log4j, log4net, site) have their own CVS module with distinct lists  
> of committer and change notifications.  The quote from the SVN book  
> suggests that if we use a single repo for Logging Services may  
> require or encourage that we unify the committer lists and change  
> notification.  That is have Logging Services committers who have  
> write access to all products (instead of log4j committers, log4net  
> committers, etc) and have all change notifications go to  
> svn@logging.apache.org (instead of going to log4j- 
> dev@logging.apache.org, log4cxx-dev@logging.apache.org, etc).  Is  
> that a proper understanding of the consequences of having a single  
> repo for LS?  I think that might be a good change, but we need to  
> discuss the implications.
>
>
>
>
>
>


Mime
View raw message