You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Benson Margulies <bi...@gmail.com> on 2012/03/12 03:00:09 UTC
That extra 'src'
While the site plugin is not the most important thing in creation, and
I'll probably eventually find some solution for it, I have to wonder
why you-all are attached to that extra level of src directory. The
common practice (I hesitate to write 'best' practice) is just to put
the module dirs right there at the top level. If you just happened to
switch to that, the site plugin would just roll over and cooperate.
Re: That extra 'src'
Posted by David Medinets <da...@gmail.com>.
Eclipse might be happier. Last night, I start looking at the
individual modules as separate Eclipse projects because the parent
project would not compile as an Eclipse project. I know that Eclipse
is not the only IDE and might not be the best basis for a decision,
but it does seem like many of the committers use it.
On Mon, Mar 12, 2012 at 12:27 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Mon, Mar 12, 2012 at 11:54 AM, Benson Margulies
> <bi...@gmail.com> wrote:
>> On Mon, Mar 12, 2012 at 11:16 AM, Keith Turner <ke...@deenlo.com> wrote:
>>> Just to make sure I understand, you are a saying if "<root>/src/*"
>>> were moved to "<root>/" mvn site would be happy?
>>
>> Yes. Also many people with ingrained habits of interacting with
>> multi-module maven projects.
>>
>
> Would anything other than mvn site benefit from this change? I am
> not opposed to making this change. It will make merging bugfixes from
> 1.4 to trunk slightly painful.
Re: That extra 'src'
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Mar 12, 2012 at 2:45 PM, Keith Turner <ke...@deenlo.com> wrote:
> Ok, who is going to do the move? This made me start thinking about
> how Apache works.
>
> Benson, you will be on our PMC when we graduate. Does this mean you
> will be a committer? There was some discussion that a committer may
> not be on the PMC, now I am wondering about the reverse.
So, the conventional situation is that the PMC is a subset (possibly
improper) of the committers. However, it's not the only option. There
have been discussions of situations in which a community wants to vote
someone in as part of the supervisory structure (PMC) who has no use
for, and/or hasn't ever contributed to justify, committer karma. I
could be on the PMC and not have committer karma until I've
contributed enough work, assuming that I ever did. The initial setup
of the TLP has some ambiguity to it this way; no one is going to be
really shocked and surprised I just quietly end up with karma based on
PMC membership. I am on the OpenNLP PMC for the same reason I'm listed
with you, and, in fact, I don't know if I have karma, since the
question has never come up. I rather bet that someone just took the
list from the resolution and made everyone the same in that case, and
that will happen here unless Billie takes steps to avoid it.
>
> Keith
>
> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies <bi...@gmail.com> wrote:
>> On Mon, Mar 12, 2012 at 12:27 PM, Keith Turner <ke...@deenlo.com> wrote:
>>> On Mon, Mar 12, 2012 at 11:54 AM, Benson Margulies
>>> <bi...@gmail.com> wrote:
>>>> On Mon, Mar 12, 2012 at 11:16 AM, Keith Turner <ke...@deenlo.com> wrote:
>>>>> Just to make sure I understand, you are a saying if "<root>/src/*"
>>>>> were moved to "<root>/" mvn site would be happy?
>>>>
>>>> Yes. Also many people with ingrained habits of interacting with
>>>> multi-module maven projects.
>>>>
>>>
>>> Would anything other than mvn site benefit from this change? I am
>>> not opposed to making this change. It will make merging bugfixes from
>>> 1.4 to trunk slightly painful.
>>
>> Here's my best arguments:
>>
>> 1) Maven works best when you follow the pattern. Maven, and I write as
>> a committer to it, has many traps for you when you try to stray from
>> the pattern, even when there seems to be a perfectly reasonable means
>> of configuring what you want. Following the pattern for multi-module
>> projects will pay off in the long run, even if, in the short run, all
>> it does it make the site plugin usable (thus getting you pretty
>> reports on the web site).
>>
>> 2) Least Surprise. Potential contributors who are accustomed to 'the
>> usual thing' are will always find that dir to be a pothole.
>>
>> It doesn't really make merges work much harder, since the scm's track the moves.
Re: That extra 'src'
Posted by Keith Turner <ke...@deenlo.com>.
Ok, who is going to do the move? This made me start thinking about
how Apache works.
Benson, you will be on our PMC when we graduate. Does this mean you
will be a committer? There was some discussion that a committer may
not be on the PMC, now I am wondering about the reverse.
Keith
On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies <bi...@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 12:27 PM, Keith Turner <ke...@deenlo.com> wrote:
>> On Mon, Mar 12, 2012 at 11:54 AM, Benson Margulies
>> <bi...@gmail.com> wrote:
>>> On Mon, Mar 12, 2012 at 11:16 AM, Keith Turner <ke...@deenlo.com> wrote:
>>>> Just to make sure I understand, you are a saying if "<root>/src/*"
>>>> were moved to "<root>/" mvn site would be happy?
>>>
>>> Yes. Also many people with ingrained habits of interacting with
>>> multi-module maven projects.
>>>
>>
>> Would anything other than mvn site benefit from this change? I am
>> not opposed to making this change. It will make merging bugfixes from
>> 1.4 to trunk slightly painful.
>
> Here's my best arguments:
>
> 1) Maven works best when you follow the pattern. Maven, and I write as
> a committer to it, has many traps for you when you try to stray from
> the pattern, even when there seems to be a perfectly reasonable means
> of configuring what you want. Following the pattern for multi-module
> projects will pay off in the long run, even if, in the short run, all
> it does it make the site plugin usable (thus getting you pretty
> reports on the web site).
>
> 2) Least Surprise. Potential contributors who are accustomed to 'the
> usual thing' are will always find that dir to be a pothole.
>
> It doesn't really make merges work much harder, since the scm's track the moves.
Re: That extra 'src'
Posted by Eric Newton <er...@gmail.com>.
Looks like "wiggle" might do the trick: it will inline the .rej files for
you.
-Eric
On Thu, Mar 15, 2012 at 3:02 PM, Keith Turner <ke...@deenlo.com> wrote:
> I really like how when svn merges a file that conflicts that it
> modifies the file and puts the two conflicting sections next to each
> other. This make it really easy to resolve the conflict. AFAIK with
> patch you just get these rejected hunks and have to figure where they
> overlap yourself. If anyone knows of a way to improves this I would
> love to hear it. Looking on the web this rename merge problem seems
> like an old svn problem w/ no good solution.
>
> On Thu, Mar 15, 2012 at 1:50 PM, Eric Newton <er...@gmail.com>
> wrote:
> > Ugh... you are not going to like this answer. There's apparently no help
> > in svn for resolving these file moves.
> >
> > Here's the little dance I did to get everything merged in; maybe I'll
> find
> > a reasonable way to automate it.
> >
> > 1) figure out what changes need to be merged:
> >
> > $ cd trunk
> > $ svn mergeinfo --show-revs eligible ../1.4
> > r1300277
> > r1300713
> >
> > 2) merge the first change in, get the epic fail:
> >
> > $ svn merge -c r1300277 ../1.4
> > --- Merging r1300277 into '.':
> > C src/assemble
> > Summary of conflicts:
> > Tree conflicts: 1
> >
> > 3) get a diff, but fix up the paths so it will patch:
> >
> > $ svn diff -c r1300277 ../1.4 | sed 's%../1.4/src/%%' | patch -p 0
> > patching file assemble/dist.xml
> > Hunk #1 FAILED at 39.
> > Hunk #2 FAILED at 68.
> > 2 out of 2 hunks FAILED -- saving rejects to file assemble/dist.xml.rej
> >
> > This is what you would get from a normal merge. It is a conflict. For
> the
> > moment, I'm going to ignore these changes: the trunk assembly module is
> > completely different, and might be fine the way it is: it's a bigger QA
> > question.
> >
> > 4) tell svn we're finished with the conflict:
> >
> > $ svn resolve -R --accept working .
> > Resolved conflicted state of 'src/assemble'
> >
> > 5) repeat for change r1300713:
> >
> > $ svn merge -c r1300713 ../1.4
> > --- Merging r1300713 into '.':
> > C src/assemble
> > Summary of conflicts:
> > Tree conflicts: 1
> > $ svn diff -c r1300713 ../1.4 | sed 's%../1.4/src/%%' | patch -p 0
> > patching file assemble/build.sh
> > $ svn resolve -R --accept working .
> > Resolved conflicted state of 'src/assemble'
> > $ svn commit -m 'ACCUMULO-145 merge to trunk'
> > Sending .
> > Sending assemble/build.sh
> >
> >
> >
> > On Thu, Mar 15, 2012 at 11:09 AM, Keith Turner <ke...@deenlo.com> wrote:
> >
> >> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies <
> bimargulies@gmail.com>
> >> wrote:
> >> > It doesn't really make merges work much harder, since the scm's track
> >> the moves.
> >>
> >> Does anyone have tips on this? dist.xml was modified in 1.4. I am
> >> trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
> >>
> >> $ svn merge -r 1:HEAD
> >> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
> >> --- Merging r1300182 through r1301010 into '.':
> >> C src/assemble
> >> Summary of conflicts:
> >> Tree conflicts: 1
> >> maccloud:trunk rkturn2$ svn status
> >> M .
> >> ! C src/assemble
> >> > local delete, incoming edit upon merge
> >>
> >> So I get this tree conflict. What I want it to do is to modify
> >> dist.xml in the new location in trunk, but its not doing this. I have
> >> been looking online but have not found anything yet.
> >>
> >> Keith
> >>
>
Re: That extra 'src'
Posted by Keith Turner <ke...@deenlo.com>.
I really like how when svn merges a file that conflicts that it
modifies the file and puts the two conflicting sections next to each
other. This make it really easy to resolve the conflict. AFAIK with
patch you just get these rejected hunks and have to figure where they
overlap yourself. If anyone knows of a way to improves this I would
love to hear it. Looking on the web this rename merge problem seems
like an old svn problem w/ no good solution.
On Thu, Mar 15, 2012 at 1:50 PM, Eric Newton <er...@gmail.com> wrote:
> Ugh... you are not going to like this answer. There's apparently no help
> in svn for resolving these file moves.
>
> Here's the little dance I did to get everything merged in; maybe I'll find
> a reasonable way to automate it.
>
> 1) figure out what changes need to be merged:
>
> $ cd trunk
> $ svn mergeinfo --show-revs eligible ../1.4
> r1300277
> r1300713
>
> 2) merge the first change in, get the epic fail:
>
> $ svn merge -c r1300277 ../1.4
> --- Merging r1300277 into '.':
> C src/assemble
> Summary of conflicts:
> Tree conflicts: 1
>
> 3) get a diff, but fix up the paths so it will patch:
>
> $ svn diff -c r1300277 ../1.4 | sed 's%../1.4/src/%%' | patch -p 0
> patching file assemble/dist.xml
> Hunk #1 FAILED at 39.
> Hunk #2 FAILED at 68.
> 2 out of 2 hunks FAILED -- saving rejects to file assemble/dist.xml.rej
>
> This is what you would get from a normal merge. It is a conflict. For the
> moment, I'm going to ignore these changes: the trunk assembly module is
> completely different, and might be fine the way it is: it's a bigger QA
> question.
>
> 4) tell svn we're finished with the conflict:
>
> $ svn resolve -R --accept working .
> Resolved conflicted state of 'src/assemble'
>
> 5) repeat for change r1300713:
>
> $ svn merge -c r1300713 ../1.4
> --- Merging r1300713 into '.':
> C src/assemble
> Summary of conflicts:
> Tree conflicts: 1
> $ svn diff -c r1300713 ../1.4 | sed 's%../1.4/src/%%' | patch -p 0
> patching file assemble/build.sh
> $ svn resolve -R --accept working .
> Resolved conflicted state of 'src/assemble'
> $ svn commit -m 'ACCUMULO-145 merge to trunk'
> Sending .
> Sending assemble/build.sh
>
>
>
> On Thu, Mar 15, 2012 at 11:09 AM, Keith Turner <ke...@deenlo.com> wrote:
>
>> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies <bi...@gmail.com>
>> wrote:
>> > It doesn't really make merges work much harder, since the scm's track
>> the moves.
>>
>> Does anyone have tips on this? dist.xml was modified in 1.4. I am
>> trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
>>
>> $ svn merge -r 1:HEAD
>> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
>> --- Merging r1300182 through r1301010 into '.':
>> C src/assemble
>> Summary of conflicts:
>> Tree conflicts: 1
>> maccloud:trunk rkturn2$ svn status
>> M .
>> ! C src/assemble
>> > local delete, incoming edit upon merge
>>
>> So I get this tree conflict. What I want it to do is to modify
>> dist.xml in the new location in trunk, but its not doing this. I have
>> been looking online but have not found anything yet.
>>
>> Keith
>>
Re: That extra 'src'
Posted by Eric Newton <er...@gmail.com>.
Ugh... you are not going to like this answer. There's apparently no help
in svn for resolving these file moves.
Here's the little dance I did to get everything merged in; maybe I'll find
a reasonable way to automate it.
1) figure out what changes need to be merged:
$ cd trunk
$ svn mergeinfo --show-revs eligible ../1.4
r1300277
r1300713
2) merge the first change in, get the epic fail:
$ svn merge -c r1300277 ../1.4
--- Merging r1300277 into '.':
C src/assemble
Summary of conflicts:
Tree conflicts: 1
3) get a diff, but fix up the paths so it will patch:
$ svn diff -c r1300277 ../1.4 | sed 's%../1.4/src/%%' | patch -p 0
patching file assemble/dist.xml
Hunk #1 FAILED at 39.
Hunk #2 FAILED at 68.
2 out of 2 hunks FAILED -- saving rejects to file assemble/dist.xml.rej
This is what you would get from a normal merge. It is a conflict. For the
moment, I'm going to ignore these changes: the trunk assembly module is
completely different, and might be fine the way it is: it's a bigger QA
question.
4) tell svn we're finished with the conflict:
$ svn resolve -R --accept working .
Resolved conflicted state of 'src/assemble'
5) repeat for change r1300713:
$ svn merge -c r1300713 ../1.4
--- Merging r1300713 into '.':
C src/assemble
Summary of conflicts:
Tree conflicts: 1
$ svn diff -c r1300713 ../1.4 | sed 's%../1.4/src/%%' | patch -p 0
patching file assemble/build.sh
$ svn resolve -R --accept working .
Resolved conflicted state of 'src/assemble'
$ svn commit -m 'ACCUMULO-145 merge to trunk'
Sending .
Sending assemble/build.sh
On Thu, Mar 15, 2012 at 11:09 AM, Keith Turner <ke...@deenlo.com> wrote:
> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies <bi...@gmail.com>
> wrote:
> > It doesn't really make merges work much harder, since the scm's track
> the moves.
>
> Does anyone have tips on this? dist.xml was modified in 1.4. I am
> trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
>
> $ svn merge -r 1:HEAD
> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
> --- Merging r1300182 through r1301010 into '.':
> C src/assemble
> Summary of conflicts:
> Tree conflicts: 1
> maccloud:trunk rkturn2$ svn status
> M .
> ! C src/assemble
> > local delete, incoming edit upon merge
>
> So I get this tree conflict. What I want it to do is to modify
> dist.xml in the new location in trunk, but its not doing this. I have
> been looking online but have not found anything yet.
>
> Keith
>
Re: Merging from 1.4 to trunk
Posted by Christopher Tubbs <ct...@gmail.com>.
I would say that it'd be nice if all changes in older branches were
also merged to newer branches... this keeps things linear, and helps
ensure no bug regressions (because all fixes in older versions can be
merged to newer versions, even if they don't apply). So, I would say
yes, the entire tree should be merged... for documentation purposes at
least. This means you might want to merge branch/src/core to
trunk/core, and then do a superficial merge (resolve conflicts, revert
changes, commit merge metadata only) from branch/ to trunk/ to ensure
the whole tree is documented as merged (assuming it was previously
fully merged before your changes).
On Sun, Sep 9, 2012 at 6:49 PM, Josh Elser <jo...@gmail.com> wrote:
> Right, I wasn't sure if there was guidance as to whether one should always
> make sure the entire tree is merged, or if merging of single changes is
> acceptable (assuming someone else will come by later and make sure dangling
> fixes aren't left in 1.4).
>
> On 09/09/2012 04:44 PM, Christopher Tubbs wrote:
>>
>> It seems to me that you can merge directly from branch/src/core to
>> trunk/core, or from branch/src/server to trunk/server. That, of
>> course, assumes you're only merging changes isolated to a single
>> submodule that was previously in src/
>>
>> On Sun, Sep 9, 2012 at 6:04 PM, Josh Elser<jo...@gmail.com> wrote:
>>>
>>> Looking back at my dev@accumulo history, Billie gave some guidance on how
>>> to
>>> make subversion place nicely with the change from /src/$module to
>>> /$module
>>> between 1.4 and trunk. http://accumulo.apache.org/source.html says to
>>> consult dev@accumulo for instructions.
>>>
>>> Is Billie's guidance below still the best way to get around this?
>>> Manually
>>> resolving the conflicts every time seems like a pain, but if that's how
>>> it
>>> is, so be it.
>>>
>>> Thanks.
>>>
>>> -------- Original Message --------
>>> Subject: Re: That extra 'src'
>>> Date: Tue, 20 Mar 2012 17:22:39 +0000 (GMT+00:00)
>>> From: Billie J Rinaldi<bi...@ugov.gov>
>>> Reply-To: accumulo-dev@incubator.apache.org
>>> To: accumulo-dev@incubator.apache.org
>>>
>>>
>>>
>>> I figured out a way to do this with two merges. First, merge all
>>> revisions
>>> from 1.4 to trunk; then take the list of revisions merged and merge those
>>> from 1.4/src to trunk.
>>>
>>> $ svn merge -r 1:HEAD
>>> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4 .
>>> --- Merging r1302469 through r1302913 into '.':
>>> C src/examples
>>> Summary of conflicts:
>>> Tree conflicts: 1
>>> $ svn merge -r 1302469:1302913
>>> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4/src .
>>> --- Merging r1302470 through r1302913 into '.':
>>> U examples/simple/pom.xml
>>> U
>>>
>>> examples/wikisearch/ingest/src/test/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputSplitTest.java
>>> U
>>>
>>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/SortingRFileOutputFormat.java
>>> U
>>>
>>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/BufferingRFileRecordWriter.java
>>> U
>>>
>>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputFormat.java
>>> U
>>>
>>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/LRUOutputCombiner.java
>>> U
>>>
>>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaMapper.java
>>> U examples/wikisearch/README
>>>
>>> Now I just have to resolve the tree conflict. Note that this works
>>> because
>>> we made a relatively simple change of removing a directory; if we had
>>> moved
>>> more things around, we would need to use more merge commands.
>>>
>>> Billie
>>>
>>>
>>> ----- Original Message -----
>>>>
>>>> From: "Keith Turner"<ke...@deenlo.com>
>>>> To: accumulo-dev@incubator.apache.org
>>>> Sent: Thursday, March 15, 2012 11:09:36 AM
>>>> Subject: Re: That extra 'src'
>>>> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies
>>>> <bi...@gmail.com> wrote:
>>>> > It doesn't really make merges work much harder, since the scm's
>>>> > track the moves.
>>>>
>>>> Does anyone have tips on this? dist.xml was modified in 1.4. I am
>>>> trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
>>>>
>>>> $ svn merge -r 1:HEAD
>>>> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
>>>> --- Merging r1300182 through r1301010 into '.':
>>>> C src/assemble
>>>> Summary of conflicts:
>>>> Tree conflicts: 1
>>>> maccloud:trunk rkturn2$ svn status
>>>> M .
>>>> ! C src/assemble
>>>> > local delete, incoming edit upon merge
>>>>
>>>> So I get this tree conflict. What I want it to do is to modify
>>>> dist.xml in the new location in trunk, but its not doing this. I have
>>>> been looking online but have not found anything yet.
>>>>
>>>> Keith
>>>
>>>
>
Re: Merging from 1.4 to trunk
Posted by Josh Elser <jo...@gmail.com>.
Right, I wasn't sure if there was guidance as to whether one should
always make sure the entire tree is merged, or if merging of single
changes is acceptable (assuming someone else will come by later and make
sure dangling fixes aren't left in 1.4).
On 09/09/2012 04:44 PM, Christopher Tubbs wrote:
> It seems to me that you can merge directly from branch/src/core to
> trunk/core, or from branch/src/server to trunk/server. That, of
> course, assumes you're only merging changes isolated to a single
> submodule that was previously in src/
>
> On Sun, Sep 9, 2012 at 6:04 PM, Josh Elser<jo...@gmail.com> wrote:
>> Looking back at my dev@accumulo history, Billie gave some guidance on how to
>> make subversion place nicely with the change from /src/$module to /$module
>> between 1.4 and trunk. http://accumulo.apache.org/source.html says to
>> consult dev@accumulo for instructions.
>>
>> Is Billie's guidance below still the best way to get around this? Manually
>> resolving the conflicts every time seems like a pain, but if that's how it
>> is, so be it.
>>
>> Thanks.
>>
>> -------- Original Message --------
>> Subject: Re: That extra 'src'
>> Date: Tue, 20 Mar 2012 17:22:39 +0000 (GMT+00:00)
>> From: Billie J Rinaldi<bi...@ugov.gov>
>> Reply-To: accumulo-dev@incubator.apache.org
>> To: accumulo-dev@incubator.apache.org
>>
>>
>>
>> I figured out a way to do this with two merges. First, merge all revisions
>> from 1.4 to trunk; then take the list of revisions merged and merge those
>> from 1.4/src to trunk.
>>
>> $ svn merge -r 1:HEAD
>> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4 .
>> --- Merging r1302469 through r1302913 into '.':
>> C src/examples
>> Summary of conflicts:
>> Tree conflicts: 1
>> $ svn merge -r 1302469:1302913
>> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4/src .
>> --- Merging r1302470 through r1302913 into '.':
>> U examples/simple/pom.xml
>> U
>> examples/wikisearch/ingest/src/test/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputSplitTest.java
>> U
>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/SortingRFileOutputFormat.java
>> U
>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/BufferingRFileRecordWriter.java
>> U
>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputFormat.java
>> U
>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/LRUOutputCombiner.java
>> U
>> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaMapper.java
>> U examples/wikisearch/README
>>
>> Now I just have to resolve the tree conflict. Note that this works because
>> we made a relatively simple change of removing a directory; if we had moved
>> more things around, we would need to use more merge commands.
>>
>> Billie
>>
>>
>> ----- Original Message -----
>>> From: "Keith Turner"<ke...@deenlo.com>
>>> To: accumulo-dev@incubator.apache.org
>>> Sent: Thursday, March 15, 2012 11:09:36 AM
>>> Subject: Re: That extra 'src'
>>> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies
>>> <bi...@gmail.com> wrote:
>>> > It doesn't really make merges work much harder, since the scm's
>>> > track the moves.
>>>
>>> Does anyone have tips on this? dist.xml was modified in 1.4. I am
>>> trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
>>>
>>> $ svn merge -r 1:HEAD
>>> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
>>> --- Merging r1300182 through r1301010 into '.':
>>> C src/assemble
>>> Summary of conflicts:
>>> Tree conflicts: 1
>>> maccloud:trunk rkturn2$ svn status
>>> M .
>>> ! C src/assemble
>>> > local delete, incoming edit upon merge
>>>
>>> So I get this tree conflict. What I want it to do is to modify
>>> dist.xml in the new location in trunk, but its not doing this. I have
>>> been looking online but have not found anything yet.
>>>
>>> Keith
>>
Re: Merging from 1.4 to trunk (was: That extra 'src')
Posted by Christopher Tubbs <ct...@gmail.com>.
It seems to me that you can merge directly from branch/src/core to
trunk/core, or from branch/src/server to trunk/server. That, of
course, assumes you're only merging changes isolated to a single
submodule that was previously in src/
On Sun, Sep 9, 2012 at 6:04 PM, Josh Elser <jo...@gmail.com> wrote:
> Looking back at my dev@accumulo history, Billie gave some guidance on how to
> make subversion place nicely with the change from /src/$module to /$module
> between 1.4 and trunk. http://accumulo.apache.org/source.html says to
> consult dev@accumulo for instructions.
>
> Is Billie's guidance below still the best way to get around this? Manually
> resolving the conflicts every time seems like a pain, but if that's how it
> is, so be it.
>
> Thanks.
>
> -------- Original Message --------
> Subject: Re: That extra 'src'
> Date: Tue, 20 Mar 2012 17:22:39 +0000 (GMT+00:00)
> From: Billie J Rinaldi <bi...@ugov.gov>
> Reply-To: accumulo-dev@incubator.apache.org
> To: accumulo-dev@incubator.apache.org
>
>
>
> I figured out a way to do this with two merges. First, merge all revisions
> from 1.4 to trunk; then take the list of revisions merged and merge those
> from 1.4/src to trunk.
>
> $ svn merge -r 1:HEAD
> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4 .
> --- Merging r1302469 through r1302913 into '.':
> C src/examples
> Summary of conflicts:
> Tree conflicts: 1
> $ svn merge -r 1302469:1302913
> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4/src .
> --- Merging r1302470 through r1302913 into '.':
> U examples/simple/pom.xml
> U
> examples/wikisearch/ingest/src/test/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputSplitTest.java
> U
> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/SortingRFileOutputFormat.java
> U
> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/BufferingRFileRecordWriter.java
> U
> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputFormat.java
> U
> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/LRUOutputCombiner.java
> U
> examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaMapper.java
> U examples/wikisearch/README
>
> Now I just have to resolve the tree conflict. Note that this works because
> we made a relatively simple change of removing a directory; if we had moved
> more things around, we would need to use more merge commands.
>
> Billie
>
>
> ----- Original Message -----
>>
>> From: "Keith Turner"<ke...@deenlo.com>
>> To: accumulo-dev@incubator.apache.org
>> Sent: Thursday, March 15, 2012 11:09:36 AM
>> Subject: Re: That extra 'src'
>> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies
>> <bi...@gmail.com> wrote:
>> > It doesn't really make merges work much harder, since the scm's
>> > track the moves.
>>
>> Does anyone have tips on this? dist.xml was modified in 1.4. I am
>> trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
>>
>> $ svn merge -r 1:HEAD
>> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
>> --- Merging r1300182 through r1301010 into '.':
>> C src/assemble
>> Summary of conflicts:
>> Tree conflicts: 1
>> maccloud:trunk rkturn2$ svn status
>> M .
>> ! C src/assemble
>> > local delete, incoming edit upon merge
>>
>> So I get this tree conflict. What I want it to do is to modify
>> dist.xml in the new location in trunk, but its not doing this. I have
>> been looking online but have not found anything yet.
>>
>> Keith
>
>
Merging from 1.4 to trunk (was: That extra 'src')
Posted by Josh Elser <jo...@gmail.com>.
Looking back at my dev@accumulo history, Billie gave some guidance on
how to make subversion place nicely with the change from /src/$module to
/$module between 1.4 and trunk. http://accumulo.apache.org/source.html
says to consult dev@accumulo for instructions.
Is Billie's guidance below still the best way to get around this?
Manually resolving the conflicts every time seems like a pain, but if
that's how it is, so be it.
Thanks.
-------- Original Message --------
Subject: Re: That extra 'src'
Date: Tue, 20 Mar 2012 17:22:39 +0000 (GMT+00:00)
From: Billie J Rinaldi <bi...@ugov.gov>
Reply-To: accumulo-dev@incubator.apache.org
To: accumulo-dev@incubator.apache.org
I figured out a way to do this with two merges. First, merge all revisions from 1.4 to trunk; then take the list of revisions merged and merge those from 1.4/src to trunk.
$ svn merge -r 1:HEAD https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4 .
--- Merging r1302469 through r1302913 into '.':
C src/examples
Summary of conflicts:
Tree conflicts: 1
$ svn merge -r 1302469:1302913 https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4/src .
--- Merging r1302470 through r1302913 into '.':
U examples/simple/pom.xml
U examples/wikisearch/ingest/src/test/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputSplitTest.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/SortingRFileOutputFormat.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/BufferingRFileRecordWriter.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputFormat.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/LRUOutputCombiner.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaMapper.java
U examples/wikisearch/README
Now I just have to resolve the tree conflict. Note that this works because we made a relatively simple change of removing a directory; if we had moved more things around, we would need to use more merge commands.
Billie
----- Original Message -----
> From: "Keith Turner"<ke...@deenlo.com>
> To: accumulo-dev@incubator.apache.org
> Sent: Thursday, March 15, 2012 11:09:36 AM
> Subject: Re: That extra 'src'
> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies
> <bi...@gmail.com> wrote:
> > It doesn't really make merges work much harder, since the scm's
> > track the moves.
>
> Does anyone have tips on this? dist.xml was modified in 1.4. I am
> trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
>
> $ svn merge -r 1:HEAD
> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
> --- Merging r1300182 through r1301010 into '.':
> C src/assemble
> Summary of conflicts:
> Tree conflicts: 1
> maccloud:trunk rkturn2$ svn status
> M .
> ! C src/assemble
> > local delete, incoming edit upon merge
>
> So I get this tree conflict. What I want it to do is to modify
> dist.xml in the new location in trunk, but its not doing this. I have
> been looking online but have not found anything yet.
>
> Keith
Re: That extra 'src'
Posted by Billie J Rinaldi <bi...@ugov.gov>.
I figured out a way to do this with two merges. First, merge all revisions from 1.4 to trunk; then take the list of revisions merged and merge those from 1.4/src to trunk.
$ svn merge -r 1:HEAD https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4 .
--- Merging r1302469 through r1302913 into '.':
C src/examples
Summary of conflicts:
Tree conflicts: 1
$ svn merge -r 1302469:1302913 https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4/src .
--- Merging r1302470 through r1302913 into '.':
U examples/simple/pom.xml
U examples/wikisearch/ingest/src/test/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputSplitTest.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/SortingRFileOutputFormat.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/output/BufferingRFileRecordWriter.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaInputFormat.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/LRUOutputCombiner.java
U examples/wikisearch/ingest/src/main/java/org/apache/accumulo/examples/wikisearch/ingest/WikipediaMapper.java
U examples/wikisearch/README
Now I just have to resolve the tree conflict. Note that this works because we made a relatively simple change of removing a directory; if we had moved more things around, we would need to use more merge commands.
Billie
----- Original Message -----
> From: "Keith Turner" <ke...@deenlo.com>
> To: accumulo-dev@incubator.apache.org
> Sent: Thursday, March 15, 2012 11:09:36 AM
> Subject: Re: That extra 'src'
> On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies
> <bi...@gmail.com> wrote:
> > It doesn't really make merges work much harder, since the scm's
> > track the moves.
>
> Does anyone have tips on this? dist.xml was modified in 1.4. I am
> trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
>
> $ svn merge -r 1:HEAD
> https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
> --- Merging r1300182 through r1301010 into '.':
> C src/assemble
> Summary of conflicts:
> Tree conflicts: 1
> maccloud:trunk rkturn2$ svn status
> M .
> ! C src/assemble
> > local delete, incoming edit upon merge
>
> So I get this tree conflict. What I want it to do is to modify
> dist.xml in the new location in trunk, but its not doing this. I have
> been looking online but have not found anything yet.
>
> Keith
Re: That extra 'src'
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Mar 12, 2012 at 2:34 PM, Benson Margulies <bi...@gmail.com> wrote:
> It doesn't really make merges work much harder, since the scm's track the moves.
Does anyone have tips on this? dist.xml was modified in 1.4. I am
trying to merge 1.4 changes to trunk. dist.xml has moved in trunk.
$ svn merge -r 1:HEAD
https://svn.apache.org/repos/asf/incubator/accumulo/branches/1.4
--- Merging r1300182 through r1301010 into '.':
C src/assemble
Summary of conflicts:
Tree conflicts: 1
maccloud:trunk rkturn2$ svn status
M .
! C src/assemble
> local delete, incoming edit upon merge
So I get this tree conflict. What I want it to do is to modify
dist.xml in the new location in trunk, but its not doing this. I have
been looking online but have not found anything yet.
Keith
Re: That extra 'src'
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Mar 12, 2012 at 12:27 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Mon, Mar 12, 2012 at 11:54 AM, Benson Margulies
> <bi...@gmail.com> wrote:
>> On Mon, Mar 12, 2012 at 11:16 AM, Keith Turner <ke...@deenlo.com> wrote:
>>> Just to make sure I understand, you are a saying if "<root>/src/*"
>>> were moved to "<root>/" mvn site would be happy?
>>
>> Yes. Also many people with ingrained habits of interacting with
>> multi-module maven projects.
>>
>
> Would anything other than mvn site benefit from this change? I am
> not opposed to making this change. It will make merging bugfixes from
> 1.4 to trunk slightly painful.
Here's my best arguments:
1) Maven works best when you follow the pattern. Maven, and I write as
a committer to it, has many traps for you when you try to stray from
the pattern, even when there seems to be a perfectly reasonable means
of configuring what you want. Following the pattern for multi-module
projects will pay off in the long run, even if, in the short run, all
it does it make the site plugin usable (thus getting you pretty
reports on the web site).
2) Least Surprise. Potential contributors who are accustomed to 'the
usual thing' are will always find that dir to be a pothole.
It doesn't really make merges work much harder, since the scm's track the moves.
Re: That extra 'src'
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Mar 12, 2012 at 11:54 AM, Benson Margulies
<bi...@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 11:16 AM, Keith Turner <ke...@deenlo.com> wrote:
>> Just to make sure I understand, you are a saying if "<root>/src/*"
>> were moved to "<root>/" mvn site would be happy?
>
> Yes. Also many people with ingrained habits of interacting with
> multi-module maven projects.
>
Would anything other than mvn site benefit from this change? I am
not opposed to making this change. It will make merging bugfixes from
1.4 to trunk slightly painful.
Re: That extra 'src'
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Mar 12, 2012 at 11:16 AM, Keith Turner <ke...@deenlo.com> wrote:
> Just to make sure I understand, you are a saying if "<root>/src/*"
> were moved to "<root>/" mvn site would be happy?
Yes. Also many people with ingrained habits of interacting with
multi-module maven projects.
>
> On Sun, Mar 11, 2012 at 10:00 PM, Benson Margulies
> <bi...@gmail.com> wrote:
>> While the site plugin is not the most important thing in creation, and
>> I'll probably eventually find some solution for it, I have to wonder
>> why you-all are attached to that extra level of src directory. The
>> common practice (I hesitate to write 'best' practice) is just to put
>> the module dirs right there at the top level. If you just happened to
>> switch to that, the site plugin would just roll over and cooperate.
Re: That extra 'src'
Posted by Keith Turner <ke...@deenlo.com>.
Just to make sure I understand, you are a saying if "<root>/src/*"
were moved to "<root>/" mvn site would be happy?
On Sun, Mar 11, 2012 at 10:00 PM, Benson Margulies
<bi...@gmail.com> wrote:
> While the site plugin is not the most important thing in creation, and
> I'll probably eventually find some solution for it, I have to wonder
> why you-all are attached to that extra level of src directory. The
> common practice (I hesitate to write 'best' practice) is just to put
> the module dirs right there at the top level. If you just happened to
> switch to that, the site plugin would just roll over and cooperate.
Re: That extra 'src'
Posted by Billie J Rinaldi <bi...@ugov.gov>.
On Sunday, March 11, 2012 10:00:09 PM, "Benson Margulies" <bi...@gmail.com> wrote:
> While the site plugin is not the most important thing in creation, and
> I'll probably eventually find some solution for it, I have to wonder
> why you-all are attached to that extra level of src directory. The
> common practice (I hesitate to write 'best' practice) is just to put
> the module dirs right there at the top level. If you just happened to
> switch to that, the site plugin would just roll over and cooperate.
I'd be fine with that. Anyone else have feelings about it?
Billie