Hoss, you and I should see if we can wrangle some of the SVN guys at ApacheCon
and see if we can get this stuff straightened out.
On Oct 24, 2010, at 8:33 PM, Yonik Seeley wrote:
Another downside to the current situation - svn log shows all these
updates to the mergeprops, so we're losing the
Another downside to the current situation - svn log shows all these
updates to the mergeprops, so we're losing the real updates in the
noise.
Maybe we should try to merge only from trunk to branch_3x, so at least
trunk says relatively clean. Making sense of branch_3x is getting
very difficult.
On Oct 19, 2010, at 4:14 PM, Robert Muir wrote:
On Tue, Oct 19, 2010 at 3:51 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Hmm but how does this explain how the number of mergeprops has grown
so much recently? I think recent merges have generally been toplevel?
i introduced
No. Once the files have a property they have it irreversible. This is why
single-file merges are a no-go.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Grant Ingersoll [mailto:gsing...@apache.org]
On Wed, Oct 20, 2010 at 7:01 AM, Grant Ingersoll gsing...@apache.org wrote:
Couldn't 3.x move contrib/analysis to modules? We could just move it to
contrib as part of the release packaging if the goal is to be consistent,
but otherwise who cares where it is located?
Would that reduce
On Mon, Oct 18, 2010 at 3:03 PM, Grant Ingersoll gsing...@apache.org wrote:
It was just a bit of a shocker for me the first time I did it and I see like
30 files changed when I only changed one file.
Me too. In fact I think it's ridiculous -- violates principle of
least surprise. I
FWIW, the commit notices are just an SVN post-commit hook that uses the
svn-mailer tool [http://opensource.perlig.de/svnmailer/]. I believe
Grant has commit rights to that file - it is in the infra SVN right next
to the old asf-auth file.
Right now I have no idea whether svn-mailer can support
On Oct 19, 2010, at 7:06 AM, Upayavira wrote:
FWIW, the commit notices are just an SVN post-commit hook that uses the
svn-mailer tool [http://opensource.perlig.de/svnmailer/]. I believe
Grant has commit rights to that file - it is in the infra SVN right next
to the old asf-auth file.
Yes, I
: FWIW, I get the sense that a lot of other projects deal with merges. What do
they do?
I suspect they do merges properly and avoid this problem entirely.
Bottom Line: if *all* merges happen at the top level, then this problem
won't exist -- mergeinfo props get added to individual files only
On Oct 19, 2010, at 3:04 PM, Chris Hostetter wrote:
: FWIW, I get the sense that a lot of other projects deal with merges. What
do they do?
I suspect they do merges properly and avoid this problem entirely.
Bottom Line: if *all* merges happen at the top level, then this problem
Hi Grant,
The individual merges are there since long time. And the additional ones
came in later. As I said before (answer to first mail on this thread): The
problem is that once a file gets a separate merge property not inherited
from its parent folder, this merge prop must be updated on every
On Tue, Oct 19, 2010 at 3:29 PM, Grant Ingersoll gsing...@apache.org wrote:
I will go take a look at it, but as far as I could tell, I merged at the top
level, but maybe IntelliJ does individual file merges and I wasn't aware of
it (I believe I said merge trunk to branch_3x and then picked
On Tue, Oct 19, 2010 at 3:51 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Hmm but how does this explain how the number of mergeprops has grown
so much recently? I think recent merges have generally been toplevel?
i introduced a lot of them by combining trunk's analyzers into
Hi Upayavira,
Thanks for the hint. Indeed with changing the config file (which allows
special configs for specific subtrees of the svn, so we can do it only for
Lucene), we can do it very easy:
http://opensource.perlig.de/svnmailer/doc-1.0/#groups-generate-diffs
The generate_diffs option
(I am allowed to see it).
I mean: (if I am allowed to see it.)
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Tuesday, October 19, 2010 11:21 PM
To:
On Oct 17, 2010, at 10:58 AM, Robert Muir wrote:
Lets say i change a single line of code, and merge it back to the 3x_branch.
Currently we get 6 or 7 emails of mergeproperty changes to the
commits@ list... this is making it difficult or impossible for
backports to be reviewed at all... I
What commands do you want me to run?
On Oct 17, 2010, at 11:27 AM, Uwe Schindler wrote:
Hi Daniel,
I already proposed something similar to our developers list and also
explained, why it is a bad idea to merge single files (see attached mail).
Still our/my opinion: It may be better, to
On Mon, Oct 18, 2010 at 12:47 PM, Grant Ingersoll gsing...@apache.org wrote:
I find it onerous that one need do a merge for this kind of thing period.
Why not just apply the patch a second time? Sure, something is lost in SVN,
but it's covered elsewhere. Of course, the flip side is that
: I find it onerous that one need do a merge for this kind of thing
: period. Why not just apply the patch a second time? Sure, something is
: lost in SVN, but it's covered elsewhere. Of course, the flip side is
: that by not doing it, it becomes all that much harder to merge in the
:
Hi Grant,
Not yet decided/investigated, this was more a question to infra, if it would
be possible to set this up. :-) I have to check a config from an SVN server
that supports merging. Where are the Apach config files for SVN? Can I view
them?
Else, I agree with Robert: I also want to track all
On Oct 18, 2010, at 2:07 PM, Uwe Schindler wrote:
Hi Grant,
Not yet decided/investigated, this was more a question to infra, if it would
be possible to set this up. :-) I have to check a config from an SVN server
that supports merging. Where are the Apach config files for SVN? Can I view
Hi Daniel,
I already proposed something similar to our developers list and also
explained, why it is a bad idea to merge single files (see attached mail).
Still our/my opinion: It may be better, to simply provide optionally plain
diffs without metadata for commit mails (on request of a project,
22 matches
Mail list logo
