You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2014/07/10 18:04:29 UTC
Can we stop the wild commits RIGHT NOW please?
Hi Werner,
I'm seeing commits from you which make absolutely no sense including
removing and re-adding folders that are obviously not related to
anything that you are working on. See an example below.
Can you stop this immediately please?
Hopefully it's just something very wrong with the svn client that you
are using, but whatever the cause this needs to stop.
-Bertrand
Author: wkeil
Date: Thu Jul 10 01:09:17 2014
New Revision: 1609359
URL: http://svn.apache.org/r1609359
Log: (empty)
Added:
incubator/devicemap/trunk/browsermap/.travis.yml
- copied unchanged from r1609358,
incubator/devicemap/trunk/browsermap/trunk/.travis.yml
Removed:
incubator/devicemap/trunk/browsermap/trunk/.travis.yml
Author: wkeil
Date: Thu Jul 10 01:15:14 2014
New Revision: 1609364
URL: http://svn.apache.org/r1609364
Log: (empty)
Removed:
incubator/devicemap/trunk/browsermap/src/main/js/
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Radu Cotescu <ra...@apache.org>.
Hi Werner,
If you look at the comments from [1] you'll see that it was easier for
INFRA to set the GitHub mirror with the folder structure from r1543040.
Reverting takes a few minutes. Changing an INFRA script definitely takes
more.
Since I'd like to release the BrowserMap module soon (this time following
the ASF process of doing that) it would be nice if you could just revert
your changes for that folder.
Thanks,
Radu
On Mon, Jul 14, 2014 at 5:34 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Mon, Jul 14, 2014 at 4:05 PM, Werner Keil <we...@gmail.com>
> wrote:
> > ...Will see what I can do. There was however a very mean and redundant
> > duplication of code kind of like /trunk/browsermap/trunk...
>
> For now, please just revert your commits as Radu asked for - reverting
> shouldn't take more than a few minutes so that
> https://github.com/apache/devicemap-browsermap/ comes back to life,
> and we can always discuss changes later.
>
> -Bertrand
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Werner Keil <we...@gmail.com>.
Radu,
Glad to see some activity also from your side.
That is first and foremost my area of interest. OpenDDR created quite some
positive momentum after several other Open Source projects either died or
got locked away like WURFL in this Area.
Based on code assessment and mutual trust in a joint effort for the greater
Good of the commnunity I donated code on behalf of OpenDDR. None of this is
outdated or wrong since then, as the WURFL fraction or (oddly;-) Reza
repeatedly said. It fully implements the W3C standard. The remaining more
popular commercial competitors like DeviceAtlas or DetectRight do so, too.
Some offer different APIs, so can WE. Those who don't want to understand
it, mainly Reza created a hostile, heated series of flames seeming almost
like he's been bribed by the WURFL folks to disrupt and destroy the
project?;-O
That POM change affects all downstream projects and he didn't bother to
adjust them. Not to mention the attempt to "fork " the project, while many
examples and "Wiki" like doc pages are still scattered across personal
sites (not just his) where it is hard to find them instead of improving the
Apache site.
If that Git mirror must have a common folder, then naming it
"/trunk/browsermap/git" or similar instead of /trunk../trunk would be
enough. Ideally SVN tags could be under /tags/browsermap, too alongside
other tags?;-)
In fact I doubt, a roll-back of a rXxx of yours should destroy those tags I
placed with others. There could be a second copy then.
Werner
Am 14.07.2014 23:43 schrieb "Radu Cotescu" <ra...@apache.org>:
> Hi Werner,
>
> While you're right about having two src folders inside browsermap at
> r1543048 (which is totally my fault, as I've used git-svn instead of pure
> svn), that alone doesn't justify moving stuff around without asking the
> list about it, especially since browsermap was outside of your area of
> interest. Even if we don't explicitly use the RTC [2] policy in our project
> I do hope that we act accordingly and try to figure out *on_the_list* why
> some bits and pieces may not look as we expect them to and collectively
> decide on what needs to be changed.
>
> To solve the browsermap issue I'd would still like you to revert the
> changes you had made that affected the browsermap folder, after which I can
> clean up the empty folders and add a README file explaining why we have
> that confusing folder structure. Part of it is because we're using SVN, but
> that's a topic for another time and thread.
>
> If you're still pointing fingers at Reza (though I really don't understand
> what you have against him), he publicly declared on the list multiple times
> that he's working on implementing a different API than the proposed W3C DDR
> Simple API which means that you should expect to see lots of code changes
> for the Java client. Furthermore, the fact that he was preparing a release
> didn't mean that we would necessarily release that artifact - that's why we
> vote on releasing artifacts. Changing code / repo structure arbitrarily
> just before the release doesn't allow us to move forward at all - it just
> reflects how immature our project is.
>
> Regarding ASF's JIRA: create an account at [3] and then ask Bertrand to
> add your account to the the DMAP project.
>
> I expect that a selected crowd like us can do more than flaming and
> arguing; maybe release something?! Let's work together rather than against
> each other.
>
> Cheers,
> Radu
>
> [2] - http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> [3] - https://issues.apache.org/jira/secure/Dashboard.jspa
>
>
> On Mon, Jul 14, 2014 at 9:23 PM, Werner Keil <we...@gmail.com>
> wrote:
>
>> When I last Saw the SVN structure there was /trunk/browsermap/SRC,... And
>> /trunk/browsermap/trunk/SRC. Not sure if both with identical content, but
>> they Were there, that alone confusing.
>>
>> I don't recall Reza asked the list or filed a task for completely
>> refactoring the POMs from an OSGi like "org.Apache.DeviceMap.soandso" to a
>> simple "soandso". A lot of things were done without a task or ticket, also
>> because many of us still can't assign those Tickets properly😕
>>
>> Hopefully WE can address that, then you'll find me first to create a
>> ticket or similar online item for such changes.
>>
>> Werner
>> Am 14.07.2014 17:56 schrieb "Radu Cotescu" <ra...@apache.org>:
>>
>> Hi,
>>>
>>> There were no copies. The browsermap folder only contained what looked
>>> like a SVN structure, with all the code in trunk. Nothing was confusing as
>>> a README.md file in browsermap/trunk described what was there, albeit there
>>> was no explanation for why we had that folder structure.
>>>
>>> However, that's not a good reason to start moving things around without
>>> asking the list about this type of change before actually committing the
>>> said changes.
>>>
>>> Cheers,
>>> Radu
>>>
>>> P.S.: Still waiting for that revert. I don't think it's fair to ask
>>> somebody else to repair what you (accidentally) broke
>>> On Jul 14, 2014 6:32 PM, "Werner Keil" <we...@gmail.com> wrote:
>>>
>>>> Even if Radu needed the old glitch to fix the configuration, please
>>>> promise to fix that in a timely manner so the "perpetual trunk" can be
>>>> permanently resolved.
>>>>
>>>> People on conferences or Twitter tell me a lot, they find DeviceMap
>>>> hard to understand. And who can blame them, if there's a /trunk/browsermap
>>>> and an exact copy of that in /trunk/browsermap/trunk, but only the latter
>>>> is mirrored to Git?;-O
>>>>
>>>> Werner
>>>> Am 14.07.2014 16:34 schrieb "Bertrand Delacretaz" <
>>>> bdelacretaz@apache.org>:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Mon, Jul 14, 2014 at 4:05 PM, Werner Keil <we...@gmail.com>
>>>>> wrote:
>>>>> > ...Will see what I can do. There was however a very mean and
>>>>> redundant
>>>>> > duplication of code kind of like /trunk/browsermap/trunk...
>>>>>
>>>>> For now, please just revert your commits as Radu asked for - reverting
>>>>> shouldn't take more than a few minutes so that
>>>>> https://github.com/apache/devicemap-browsermap/ comes back to life,
>>>>> and we can always discuss changes later.
>>>>>
>>>>> -Bertrand
>>>>>
>>>>
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Radu Cotescu <ra...@apache.org>.
Hi Werner,
While you're right about having two src folders inside browsermap at
r1543048 (which is totally my fault, as I've used git-svn instead of pure
svn), that alone doesn't justify moving stuff around without asking the
list about it, especially since browsermap was outside of your area of
interest. Even if we don't explicitly use the RTC [2] policy in our project
I do hope that we act accordingly and try to figure out *on_the_list* why
some bits and pieces may not look as we expect them to and collectively
decide on what needs to be changed.
To solve the browsermap issue I'd would still like you to revert the
changes you had made that affected the browsermap folder, after which I can
clean up the empty folders and add a README file explaining why we have
that confusing folder structure. Part of it is because we're using SVN, but
that's a topic for another time and thread.
If you're still pointing fingers at Reza (though I really don't understand
what you have against him), he publicly declared on the list multiple times
that he's working on implementing a different API than the proposed W3C DDR
Simple API which means that you should expect to see lots of code changes
for the Java client. Furthermore, the fact that he was preparing a release
didn't mean that we would necessarily release that artifact - that's why we
vote on releasing artifacts. Changing code / repo structure arbitrarily
just before the release doesn't allow us to move forward at all - it just
reflects how immature our project is.
Regarding ASF's JIRA: create an account at [3] and then ask Bertrand to add
your account to the the DMAP project.
I expect that a selected crowd like us can do more than flaming and
arguing; maybe release something?! Let's work together rather than against
each other.
Cheers,
Radu
[2] - http://www.apache.org/foundation/glossary.html#ReviewThenCommit
[3] - https://issues.apache.org/jira/secure/Dashboard.jspa
On Mon, Jul 14, 2014 at 9:23 PM, Werner Keil <we...@gmail.com> wrote:
> When I last Saw the SVN structure there was /trunk/browsermap/SRC,... And
> /trunk/browsermap/trunk/SRC. Not sure if both with identical content, but
> they Were there, that alone confusing.
>
> I don't recall Reza asked the list or filed a task for completely
> refactoring the POMs from an OSGi like "org.Apache.DeviceMap.soandso" to a
> simple "soandso". A lot of things were done without a task or ticket, also
> because many of us still can't assign those Tickets properly😕
>
> Hopefully WE can address that, then you'll find me first to create a
> ticket or similar online item for such changes.
>
> Werner
> Am 14.07.2014 17:56 schrieb "Radu Cotescu" <ra...@apache.org>:
>
> Hi,
>>
>> There were no copies. The browsermap folder only contained what looked
>> like a SVN structure, with all the code in trunk. Nothing was confusing as
>> a README.md file in browsermap/trunk described what was there, albeit there
>> was no explanation for why we had that folder structure.
>>
>> However, that's not a good reason to start moving things around without
>> asking the list about this type of change before actually committing the
>> said changes.
>>
>> Cheers,
>> Radu
>>
>> P.S.: Still waiting for that revert. I don't think it's fair to ask
>> somebody else to repair what you (accidentally) broke
>> On Jul 14, 2014 6:32 PM, "Werner Keil" <we...@gmail.com> wrote:
>>
>>> Even if Radu needed the old glitch to fix the configuration, please
>>> promise to fix that in a timely manner so the "perpetual trunk" can be
>>> permanently resolved.
>>>
>>> People on conferences or Twitter tell me a lot, they find DeviceMap hard
>>> to understand. And who can blame them, if there's a /trunk/browsermap and
>>> an exact copy of that in /trunk/browsermap/trunk, but only the latter is
>>> mirrored to Git?;-O
>>>
>>> Werner
>>> Am 14.07.2014 16:34 schrieb "Bertrand Delacretaz" <
>>> bdelacretaz@apache.org>:
>>>
>>>> Hi,
>>>>
>>>> On Mon, Jul 14, 2014 at 4:05 PM, Werner Keil <we...@gmail.com>
>>>> wrote:
>>>> > ...Will see what I can do. There was however a very mean and redundant
>>>> > duplication of code kind of like /trunk/browsermap/trunk...
>>>>
>>>> For now, please just revert your commits as Radu asked for - reverting
>>>> shouldn't take more than a few minutes so that
>>>> https://github.com/apache/devicemap-browsermap/ comes back to life,
>>>> and we can always discuss changes later.
>>>>
>>>> -Bertrand
>>>>
>>>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Werner Keil <we...@gmail.com>.
When I last Saw the SVN structure there was /trunk/browsermap/SRC,... And
/trunk/browsermap/trunk/SRC. Not sure if both with identical content, but
they Were there, that alone confusing.
I don't recall Reza asked the list or filed a task for completely
refactoring the POMs from an OSGi like "org.Apache.DeviceMap.soandso" to a
simple "soandso". A lot of things were done without a task or ticket, also
because many of us still can't assign those Tickets properly😕
Hopefully WE can address that, then you'll find me first to create a ticket
or similar online item for such changes.
Werner
Am 14.07.2014 17:56 schrieb "Radu Cotescu" <ra...@apache.org>:
> Hi,
>
> There were no copies. The browsermap folder only contained what looked
> like a SVN structure, with all the code in trunk. Nothing was confusing as
> a README.md file in browsermap/trunk described what was there, albeit there
> was no explanation for why we had that folder structure.
>
> However, that's not a good reason to start moving things around without
> asking the list about this type of change before actually committing the
> said changes.
>
> Cheers,
> Radu
>
> P.S.: Still waiting for that revert. I don't think it's fair to ask
> somebody else to repair what you (accidentally) broke
> On Jul 14, 2014 6:32 PM, "Werner Keil" <we...@gmail.com> wrote:
>
>> Even if Radu needed the old glitch to fix the configuration, please
>> promise to fix that in a timely manner so the "perpetual trunk" can be
>> permanently resolved.
>>
>> People on conferences or Twitter tell me a lot, they find DeviceMap hard
>> to understand. And who can blame them, if there's a /trunk/browsermap and
>> an exact copy of that in /trunk/browsermap/trunk, but only the latter is
>> mirrored to Git?;-O
>>
>> Werner
>> Am 14.07.2014 16:34 schrieb "Bertrand Delacretaz" <bdelacretaz@apache.org
>> >:
>>
>>> Hi,
>>>
>>> On Mon, Jul 14, 2014 at 4:05 PM, Werner Keil <we...@gmail.com>
>>> wrote:
>>> > ...Will see what I can do. There was however a very mean and redundant
>>> > duplication of code kind of like /trunk/browsermap/trunk...
>>>
>>> For now, please just revert your commits as Radu asked for - reverting
>>> shouldn't take more than a few minutes so that
>>> https://github.com/apache/devicemap-browsermap/ comes back to life,
>>> and we can always discuss changes later.
>>>
>>> -Bertrand
>>>
>>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Radu Cotescu <ra...@apache.org>.
Hi,
There were no copies. The browsermap folder only contained what looked like
a SVN structure, with all the code in trunk. Nothing was confusing as a
README.md file in browsermap/trunk described what was there, albeit there
was no explanation for why we had that folder structure.
However, that's not a good reason to start moving things around without
asking the list about this type of change before actually committing the
said changes.
Cheers,
Radu
P.S.: Still waiting for that revert. I don't think it's fair to ask
somebody else to repair what you (accidentally) broke
On Jul 14, 2014 6:32 PM, "Werner Keil" <we...@gmail.com> wrote:
> Even if Radu needed the old glitch to fix the configuration, please
> promise to fix that in a timely manner so the "perpetual trunk" can be
> permanently resolved.
>
> People on conferences or Twitter tell me a lot, they find DeviceMap hard
> to understand. And who can blame them, if there's a /trunk/browsermap and
> an exact copy of that in /trunk/browsermap/trunk, but only the latter is
> mirrored to Git?;-O
>
> Werner
> Am 14.07.2014 16:34 schrieb "Bertrand Delacretaz" <bdelacretaz@apache.org
> >:
>
>> Hi,
>>
>> On Mon, Jul 14, 2014 at 4:05 PM, Werner Keil <we...@gmail.com>
>> wrote:
>> > ...Will see what I can do. There was however a very mean and redundant
>> > duplication of code kind of like /trunk/browsermap/trunk...
>>
>> For now, please just revert your commits as Radu asked for - reverting
>> shouldn't take more than a few minutes so that
>> https://github.com/apache/devicemap-browsermap/ comes back to life,
>> and we can always discuss changes later.
>>
>> -Bertrand
>>
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Werner Keil <we...@gmail.com>.
Even if Radu needed the old glitch to fix the configuration, please promise
to fix that in a timely manner so the "perpetual trunk" can be permanently
resolved.
People on conferences or Twitter tell me a lot, they find DeviceMap hard to
understand. And who can blame them, if there's a /trunk/browsermap and an
exact copy of that in /trunk/browsermap/trunk, but only the latter is
mirrored to Git?;-O
Werner
Am 14.07.2014 16:34 schrieb "Bertrand Delacretaz" <bd...@apache.org>:
> Hi,
>
> On Mon, Jul 14, 2014 at 4:05 PM, Werner Keil <we...@gmail.com>
> wrote:
> > ...Will see what I can do. There was however a very mean and redundant
> > duplication of code kind of like /trunk/browsermap/trunk...
>
> For now, please just revert your commits as Radu asked for - reverting
> shouldn't take more than a few minutes so that
> https://github.com/apache/devicemap-browsermap/ comes back to life,
> and we can always discuss changes later.
>
> -Bertrand
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Jul 14, 2014 at 4:05 PM, Werner Keil <we...@gmail.com> wrote:
> ...Will see what I can do. There was however a very mean and redundant
> duplication of code kind of like /trunk/browsermap/trunk...
For now, please just revert your commits as Radu asked for - reverting
shouldn't take more than a few minutes so that
https://github.com/apache/devicemap-browsermap/ comes back to life,
and we can always discuss changes later.
-Bertrand
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Werner Keil <we...@gmail.com>.
Radu,
Will see what I can do. There was however a very mean and redundant
duplication of code kind of like /trunk/browsermap/trunk.
Do you really say Git insists on this bad behavior or could the mirror be
better structured?[?]
/repos/asf/incubator/devicemap*/trunk/browsermap/trunk*
shows that redundancy.
Could the Git pull script (we don't have control over that from the SVN
side) be fixed to avoid this redundancy?
And simply point to /repos/asf/incubator/devicemap*/trunk/browsermap*
without the extra /trunk?
That should fix the sync problem.
Werner
On Mon, Jul 14, 2014 at 3:38 PM, Radu Cotescu <ra...@apache.org> wrote:
> Hi Werner,
>
> Some of your SVN commits have rendered the public Apache DeviceMap
> BrowserMap GitHub mirror [0] unusable. I specifically asked for a GitHub
> public mirror for that submodule in order to have TravisCI check all the
> commits to that module for consistency, by running the test suite we have
> for BrowserMap. For more details please check INFRA-6220 [1]; the
> browsermap folder must be organised like a SVN repo (having branches, tags,
> trunk subfolders).
>
> *TL;DR: *- Werner, please revert your changes touching
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/browsermap/ to the
> state from r1543048.
>
> Thanks,
> Radu
>
> [0] - https://github.com/apache/devicemap-browsermap/
> [1] - https://issues.apache.org/jira/browse/INFRA-6220
>
>
>
>
>
> On Thu, Jul 10, 2014 at 10:30 PM, Werner Keil <we...@gmail.com>
> wrote:
>
> > If you prefer a /releases folder similar to /tags, please create it.
> > Those tags included in a confirmed release might be copied or moved
> there,
> > but is this a common practice by other projects elsewhere?
> >
> > All initial contributions except "data" which is somewhat special went to
> > /contrib, not sure, what made browsermap contributions different?
> >
> > Werner
> >
> > On Thu, Jul 10, 2014 at 8:31 PM, Bertrand Delacretaz <
> > bdelacretaz@apache.org
> > > wrote:
> >
> > > On Thursday, July 10, 2014, Werner Keil <we...@gmail.com> wrote:
> > >
> > > > In the DeviceMap SVN. under /tags/*
> > >
> > > I agree there's kind of a mess under
> > > http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - for now we
> > can
> > > create a "releases" folder there and put the tags for what we actually
> > > release there.
> > >
> > > > ...Could we put a readme or something else in a section if just a
> > single
> > > > folder is "pulled" by another repo without the SVN folder itself
> being
> > > > evident?..
> > >
> > > I'm not sure I understand -
> > > http://svn.apache.org/repos/asf/incubator/devicemap is the canonical
> > > repository for this project, we don't care whether other copies exist.
> > >
> > > > ...It looked like browsermap had its own isolated Git repo for
> historic
> > > > reasons and the SVN copy was a disconnected leftover...
> > >
> > > Same here,
> > > http://svn.apache.org/repos/asf/incubator/devicemap/trunk/browsermap/
> is
> > > the BrowserMap code that's been donated to DeviceMap, we don't really
> > care
> > > if there existing copies of that code elsewhere.
> > >
> > > -Bertrand
> > >
> >
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Radu Cotescu <ra...@apache.org>.
Hi Werner,
Some of your SVN commits have rendered the public Apache DeviceMap
BrowserMap GitHub mirror [0] unusable. I specifically asked for a GitHub
public mirror for that submodule in order to have TravisCI check all the
commits to that module for consistency, by running the test suite we have
for BrowserMap. For more details please check INFRA-6220 [1]; the
browsermap folder must be organised like a SVN repo (having branches, tags,
trunk subfolders).
*TL;DR: *- Werner, please revert your changes touching
http://svn.apache.org/viewvc/incubator/devicemap/trunk/browsermap/ to the
state from r1543048.
Thanks,
Radu
[0] - https://github.com/apache/devicemap-browsermap/
[1] - https://issues.apache.org/jira/browse/INFRA-6220
On Thu, Jul 10, 2014 at 10:30 PM, Werner Keil <we...@gmail.com> wrote:
> If you prefer a /releases folder similar to /tags, please create it.
> Those tags included in a confirmed release might be copied or moved there,
> but is this a common practice by other projects elsewhere?
>
> All initial contributions except "data" which is somewhat special went to
> /contrib, not sure, what made browsermap contributions different?
>
> Werner
>
> On Thu, Jul 10, 2014 at 8:31 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> > wrote:
>
> > On Thursday, July 10, 2014, Werner Keil <we...@gmail.com> wrote:
> >
> > > In the DeviceMap SVN. under /tags/*
> >
> > I agree there's kind of a mess under
> > http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - for now we
> can
> > create a "releases" folder there and put the tags for what we actually
> > release there.
> >
> > > ...Could we put a readme or something else in a section if just a
> single
> > > folder is "pulled" by another repo without the SVN folder itself being
> > > evident?..
> >
> > I'm not sure I understand -
> > http://svn.apache.org/repos/asf/incubator/devicemap is the canonical
> > repository for this project, we don't care whether other copies exist.
> >
> > > ...It looked like browsermap had its own isolated Git repo for historic
> > > reasons and the SVN copy was a disconnected leftover...
> >
> > Same here,
> > http://svn.apache.org/repos/asf/incubator/devicemap/trunk/browsermap/ is
> > the BrowserMap code that's been donated to DeviceMap, we don't really
> care
> > if there existing copies of that code elsewhere.
> >
> > -Bertrand
> >
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Werner Keil <we...@gmail.com>.
If you prefer a /releases folder similar to /tags, please create it.
Those tags included in a confirmed release might be copied or moved there,
but is this a common practice by other projects elsewhere?
All initial contributions except "data" which is somewhat special went to
/contrib, not sure, what made browsermap contributions different?
Werner
On Thu, Jul 10, 2014 at 8:31 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Thursday, July 10, 2014, Werner Keil <we...@gmail.com> wrote:
>
> > In the DeviceMap SVN. under /tags/*
>
> I agree there's kind of a mess under
> http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - for now we can
> create a "releases" folder there and put the tags for what we actually
> release there.
>
> > ...Could we put a readme or something else in a section if just a single
> > folder is "pulled" by another repo without the SVN folder itself being
> > evident?..
>
> I'm not sure I understand -
> http://svn.apache.org/repos/asf/incubator/devicemap is the canonical
> repository for this project, we don't care whether other copies exist.
>
> > ...It looked like browsermap had its own isolated Git repo for historic
> > reasons and the SVN copy was a disconnected leftover...
>
> Same here,
> http://svn.apache.org/repos/asf/incubator/devicemap/trunk/browsermap/ is
> the BrowserMap code that's been donated to DeviceMap, we don't really care
> if there existing copies of that code elsewhere.
>
> -Bertrand
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thursday, July 10, 2014, Werner Keil <we...@gmail.com> wrote:
> In the DeviceMap SVN. under /tags/*
I agree there's kind of a mess under
http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - for now we can
create a "releases" folder there and put the tags for what we actually
release there.
> ...Could we put a readme or something else in a section if just a single
> folder is "pulled" by another repo without the SVN folder itself being
> evident?..
I'm not sure I understand -
http://svn.apache.org/repos/asf/incubator/devicemap is the canonical
repository for this project, we don't care whether other copies exist.
> ...It looked like browsermap had its own isolated Git repo for historic
> reasons and the SVN copy was a disconnected leftover...
Same here,
http://svn.apache.org/repos/asf/incubator/devicemap/trunk/browsermap/ is
the BrowserMap code that's been donated to DeviceMap, we don't really care
if there existing copies of that code elsewhere.
-Bertrand
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Werner Keil <we...@gmail.com>.
In the DeviceMap SVN. under /tags/*
Could we put a readme or something else in a section if just a single
folder is "pulled" by another repo without the SVN folder itself being
evident?
It looked like browsermap had its own isolated Git repo for historic
reasons and the SVN copy was a disconnected leftover.
Werner
On Thu, Jul 10, 2014 at 6:32 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Thu, Jul 10, 2014 at 6:25 PM, Werner Keil <we...@gmail.com>
> wrote:
> > ...Tags say "1.0.4", so is that graduated already? If so why isn't there
> a
> > download, or is it just a different label...
>
> Which tags exactly, what URL?
>
> There's no relationship between version numbers and graduating, we
> could very well release devicemap modules with version 16.64 if we
> like that.
>
> -Bertrand
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jul 10, 2014 at 6:25 PM, Werner Keil <we...@gmail.com> wrote:
> ...Tags say "1.0.4", so is that graduated already? If so why isn't there a
> download, or is it just a different label...
Which tags exactly, what URL?
There's no relationship between version numbers and graduating, we
could very well release devicemap modules with version 16.64 if we
like that.
-Bertrand
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Werner Keil <we...@gmail.com>.
There is no evicende in the SVN repo that something is mirrored, the Git
repository shows some config files.
All svn tags of browsermap are preserved under /tags, but the most
important question is, how it relates to DeviceMap and where it stands with
regards to incubation?
Tags say "1.0.4", so is that graduated already? If so why isn't there a
download, or is it just a different label.
Thanks for the clarification
On Thu, Jul 10, 2014 at 6:14 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Thu, Jul 10, 2014 at 6:12 PM, Werner Keil <we...@gmail.com>
> wrote:
> > ...Can you clarify that? And why SVN (or only a single folder) is
> mirrored to
> > Git, not all of DeviceMap?...
>
> we might not have mirrored everything, but whatever happens it's easy
> to verify what your svn commits will do before actually executing
> them, to avoid messing up with things that you don't mean to modify.
>
> -Bertrand
>
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jul 10, 2014 at 6:12 PM, Werner Keil <we...@gmail.com> wrote:
> ...Can you clarify that? And why SVN (or only a single folder) is mirrored to
> Git, not all of DeviceMap?...
we might not have mirrored everything, but whatever happens it's easy
to verify what your svn commits will do before actually executing
them, to avoid messing up with things that you don't mean to modify.
-Bertrand
Re: Can we stop the wild commits RIGHT NOW please?
Posted by Werner Keil <we...@gmail.com>.
It seems the Git repository is mirrored from a small subsection of the SVN
codebase, at least telling from GitHub.
There's nothing wrong with the SVN client, but as Browsermap was said to be
on the Apache Git repo it seemed a relic from the past.
Can you clarify that? And why SVN (or only a single folder) is mirrored to
Git, not all of DeviceMap?
Thanks,
Werner
On Thu, Jul 10, 2014 at 6:04 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi Werner,
>
> I'm seeing commits from you which make absolutely no sense including
> removing and re-adding folders that are obviously not related to
> anything that you are working on. See an example below.
>
> Can you stop this immediately please?
>
> Hopefully it's just something very wrong with the svn client that you
> are using, but whatever the cause this needs to stop.
>
> -Bertrand
>
> Author: wkeil
> Date: Thu Jul 10 01:09:17 2014
> New Revision: 1609359
>
> URL: http://svn.apache.org/r1609359
> Log: (empty)
>
> Added:
> incubator/devicemap/trunk/browsermap/.travis.yml
> - copied unchanged from r1609358,
> incubator/devicemap/trunk/browsermap/trunk/.travis.yml
> Removed:
> incubator/devicemap/trunk/browsermap/trunk/.travis.yml
>
> Author: wkeil
> Date: Thu Jul 10 01:15:14 2014
> New Revision: 1609364
>
> URL: http://svn.apache.org/r1609364
> Log: (empty)
>
> Removed:
> incubator/devicemap/trunk/browsermap/src/main/js/
>