Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of costin@gmail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=L6ZIx0z+JI7dGy8T7tnhvofzW2Nqkc95qLiSRFQTNlvs5FkfN6xa+f4pv/ljL2MdrFYiU3lHaQKHT/QxBYzHv6MEC9CvRnMEV2m8aRm0AnM8hQitmZJFoQRaQIdyhnL3L5/eyImir9OTGvBCfVe9TAN7+eHUPlUwcSfAvSyyx10=
Message-ID: <96e4b5230607210833t4414a00dpe6858863edba0be3@mail.gmail.com>
Date: Fri, 21 Jul 2006 08:33:21 -0700
From: "Costin Manolache" <costin@apache.org>
Sender: costin@gmail.com
To: "Garrett Rooney" <rooneg@electricjellyfish.net>
Subject: Re: Excessive Lock/Unlock Traffic
Cc: dev@tomcat.apache.org, "ASF Infrastructure" <infrastructure@apache.org>
In-Reply-To: <7edfeeef0607210751q95dd11cx926b648da107a897@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_13938_17725718.1153496001158"
References: <7edfeeef0607201022g55d8501ema1d99944ad790d26@mail.gmail.com>
	 <96e4b5230607210627p2aca032by563624dd197437ba@mail.gmail.com>
	 <7edfeeef0607210751q95dd11cx926b648da107a897@mail.gmail.com>

------=_Part_13938_17725718.1153496001158
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm pretty sure Mladen didn't intentionally do a 'svn lock/unlock' on each
file. Maybe his IDE did - he can
comment on what commands he used to perform the operation.

However, I don't see any reason for svn to send a mail whenever a file is
locked or unlocked - the
purpose ( AFAIK ) is to allow review and inform people of repository
activity - locking a file
doesn't look like something you would "-1", it's more of an internal svn/dav
thing.

Changing a property on all files in a repository is a normal, legal
operation that other
projects may do ( tomcat will probably avoid this in future :-).

If you think svn is correct in sending lock/unlock/proppatch mails for each
individual file ( without at least agreggating them ) - then
it would be good to inform projects on what to expect, how to turn off mail
before doing such changes, or
how to do this kind of changes without locking.

Costin


On 7/21/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
>
> On 7/21/06, Costin Manolache <costin@gmail.com> wrote:
> > Good to hear from infrastructure@ !
> >
> > We all agree that the svn lock/svn unlock traffic was a bad thing, and
> > even worse that 2 mails were sent for each file in the repository.
> > AFAIK this is result of changing a simple property in the tomcat
> repository
> > ( for
> > line ending ), and it's a serious bug in svn or how svn is configured to
> > generate all this spam. I think the change made in tomcat is perfectly
> > reasonable, and other projects may do similar things - I hope svn
> > will be fixed, or maybe infrastructure can add some filters to drop
> > such messages.
>
> It's not a bug in how svn is configured, it's a "bug" in the user
> understanding of the need for use of 'svn lock'.  You do not need to
> use svn lock just because you want to change the line endings.  Anyone
> who tells you otherwise is just plain wrong, and I'm saying that both
> with my ASF infra hat on and my Subversion developer hat on.  People
> change eol styles in repositories all over the world constantly
> without ever using 'svn lock' and 'svn unlock'.
>
> The only real justification for use of 'svn lock' is when you're
> making modifications to a file that intrinsically cannot be merged,
> and thus you want to prevent someone else from modifying it at the
> same time.  This might include images, .doc files, etc.  In that case
> the notification is critical because you don't want people to find out
> that the file has been locked when they go to do their commit.  In
> virtually all other cases (and especially in the ASF repository with
> its goal of collaborative development) there is no reason to ever use
> 'svn lock' at all.
>
> -garrett
>

------=_Part_13938_17725718.1153496001158--