Tree conflict on 'grass_trunk/general/g.list'
> local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'grass_trunk/general/g.list'
Tree conflict on 'grass_trunk/general/g.remove'
> local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
svn status | grep -v "^?"
D general/g.list
D general/g.list/Makefile
D general/g.list/g.list.html
D general/g.list/main.c
D general/g.list/testsuite
D general/g.list/testsuite/test_g_list.py
D general/g.remove
D general/g.remove/Makefile
D general/g.remove/check_reclass.c
D general/g.remove/g.remove.html
D general/g.remove/main.c
D general/g.remove/testsuite
D general/g.remove/testsuite/test_g_remove.py
On Tue, Sep 30, 2014 at 3:15 AM, Markus Neteler <neteler@osgeo.org> wrote:
Hi,
likely you will be affected by this recent issue:
Tree conflict on 'grass_trunk/general/g.list'
> local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'grass_trunk/general/g.list'
Tree conflict on 'grass_trunk/general/g.remove'
> local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
svn status | grep -v "^?"
D general/g.list
D general/g.list/Makefile
D general/g.list/g.list.html
D general/g.list/main.c
D general/g.list/testsuite
D general/g.list/testsuite/test_g_list.py
D general/g.remove
D general/g.remove/Makefile
D general/g.remove/check_reclass.c
D general/g.remove/g.remove.html
D general/g.remove/main.c
D general/g.remove/testsuite
D general/g.remove/testsuite/test_g_remove.py
On Tue, Sep 30, 2014 at 5:25 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
...
Confirmed, I had to do the same in all copies too some time ago. SVN is not
really good at renaming and deleting things, it is always confused and I
really don't understand why I need to do revert.
As this almost never happened, it may have been this specific commit
being different from others.
Whatever, the solution we have.
On Tue, Sep 30, 2014 at 12:02 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Sep 30, 2014 at 5:25 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
...
> Confirmed, I had to do the same in all copies too some time ago. SVN is
not
> really good at renaming and deleting things, it is always confused and I
> really don't understand why I need to do revert.
As this almost never happened, it may have been this specific commit
being different from others.
Whatever, the solution we have.
Oh, now I hope it was not because I recommended some Git-like procedure to
Huidae which is not really what SVN wanted. Anyway, it was easy to solve
although it required manual intervention to automatic builds (at least the
one for tests).
Confirmed, I had to do the same in all copies too some time ago. SVN is not
really good at renaming and deleting things, it is always confused and I
really don’t understand why I need to do revert.
As this almost never happened, it may have been this specific commit
being different from others.
Whatever, the solution we have.
Oh, now I hope it was not because I recommended some Git-like procedure to Huidae which is not really what SVN wanted. Anyway, it was easy to solve although it required manual intervention to automatic builds (at least the one for tests).
On Tue, Sep 30, 2014 at 8:16 PM, Huidae Cho <grass4u@gmail.com> wrote:
Hmm... I "remove"d g.list/g.remove and "rename"d g.mlist/g.mremove. Maybe,
there is a better way?
In SVN it seems to be a kind a collision since it appears to maintain
the history.
Perhaps the way to go would have been (guessing):
cd general/
svn mv g.list g.list.old
svn mv g.remove g.remove.old
svn ci -m"move old code aside"
svn mv g.mlist g.list
svn mv g.mremove g.remove
svn rm g.list.old
svn rm g.remove.old
svn ci -m"subsitute old g.list/g.remove code with former g.mlist/g.mremove"
Anyway, too late However, it needs to be manually fixed in all SVN
copies around including the automated builts. @MartinL: also for winGRASS binaries of trunk
On Tue, Sep 30, 2014 at 8:16 PM, Huidae Cho <grass4u@gmail.com> wrote:
Hmm... I "remove"d g.list/g.remove and "rename"d g.mlist/g.mremove. Maybe,
there is a better way?
Did you "remove" or "svn remove"? Same for "rename". I guess you did
"svn [remove|rename]", and some other people did not "make distclean"
before "svn up". FWIW, I had no problems with your changes, doing
"make distclean" before "svn up".
Whoever compiles GRASS from source and wants the latest and greatest
(svn up), must clean the source code first with "make distclean"
before recompiling. This applies to all 4 branches. This is not GRASS
specific but the way how svn works.
Markus M
On Tue, Sep 30, 2014 at 1:19 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Tue, Sep 30, 2014 at 12:02 PM, Markus Neteler <neteler@osgeo.org>
wrote:
On Tue, Sep 30, 2014 at 5:25 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
...
> Confirmed, I had to do the same in all copies too some time ago. SVN is
> not
> really good at renaming and deleting things, it is always confused and
> I
> really don't understand why I need to do revert.
As this almost never happened, it may have been this specific commit
being different from others.
Whatever, the solution we have.
Oh, now I hope it was not because I recommended some Git-like procedure to
Huidae which is not really what SVN wanted. Anyway, it was easy to solve
although it required manual intervention to automatic builds (at least the
one for tests).
On Wed, Oct 1, 2014 at 4:43 PM, Markus Metz <markus.metz.giswork@gmail.com>
wrote:
On Tue, Sep 30, 2014 at 8:16 PM, Huidae Cho <grass4u@gmail.com> wrote:
> Hmm... I "remove"d g.list/g.remove and "rename"d g.mlist/g.mremove.
Maybe,
> there is a better way?
Did you "remove" or "svn remove"? Same for "rename". I guess you did
"svn [remove|rename]", and some other people did not "make distclean"
before "svn up". FWIW, I had no problems with your changes, doing
"make distclean" before "svn up".
Whoever compiles GRASS from source and wants the latest and greatest
(svn up), must clean the source code first with "make distclean"
before recompiling. This applies to all 4 branches. This is not GRASS
specific but the way how svn works.
make distclean or just make clean, this might be it. The message from SVN
was not much helpful, although it changed from the previous version.
But usually you don't have to do make *clean, so how to know these things
ahead (except for looking at Trac)? I don't know. Or is there some option
in SVN (from the options you are given) to use "theirs all" as it was in
previous SVN version (I don't know which)?
Markus M
>
> On Tue, Sep 30, 2014 at 1:19 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
>>
>>
>>
>> On Tue, Sep 30, 2014 at 12:02 PM, Markus Neteler <neteler@osgeo.org>
>> wrote:
>>>
>>> On Tue, Sep 30, 2014 at 5:25 PM, Vaclav Petras <wenzeslaus@gmail.com>
>>> wrote:
>>> ...
>>> > Confirmed, I had to do the same in all copies too some time ago. SVN
is
>>> > not
>>> > really good at renaming and deleting things, it is always confused
and
>>> > I
>>> > really don't understand why I need to do revert.
>>>
>>> As this almost never happened, it may have been this specific commit
>>> being different from others.
>>> Whatever, the solution we have.
>>>
>> Oh, now I hope it was not because I recommended some Git-like procedure
to
>> Huidae which is not really what SVN wanted. Anyway, it was easy to solve
>> although it required manual intervention to automatic builds (at least
the
>> one for tests).
>>
>>
>>>
>>> Markus
>>
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
On Tue, Sep 30, 2014 at 8:16 PM, Huidae Cho <grass4u@gmail.com> wrote:
Hmm… I "remove"d g.list/g.remove and "rename"d g.mlist/g.mremove. Maybe,
there is a better way?
Did you “remove” or “svn remove”? Same for “rename”. I guess you did
“svn [remove|rename]”, and some other people did not “make distclean”
before “svn up”. FWIW, I had no problems with your changes, doing
“make distclean” before “svn up”.
Whoever compiles GRASS from source and wants the latest and greatest
(svn up), must clean the source code first with “make distclean”
before recompiling. This applies to all 4 branches. This is not GRASS
specific but the way how svn works.
In this case it failed.
In my cronjob on grass.osgeo.org there well is ‘make distclean’ but the two directories remained wrong unless fixed manually.
markusN
make distclean or just make clean, this might be it. The message from SVN was not much helpful, although it changed from the previous version.
But usually you don’t have to do make *clean, so how to know these things ahead (except for looking at Trac)? I don’t know. Or is there some option in SVN (from the options you are given) to use “theirs all” as it was in previous SVN version (I don’t know which)?
Confirmed, I had to do the same in all copies too some time ago. SVN is
not
really good at renaming and deleting things, it is always confused and
I
really don’t understand why I need to do revert.
As this almost never happened, it may have been this specific commit
being different from others.
Whatever, the solution we have.
Oh, now I hope it was not because I recommended some Git-like procedure to
Huidae which is not really what SVN wanted. Anyway, it was easy to solve
although it required manual intervention to automatic builds (at least the
one for tests).
On Tue, Sep 30, 2014 at 8:16 PM, Huidae Cho <grass4u@gmail.com> wrote:
Hmm... I "remove"d g.list/g.remove and "rename"d g.mlist/g.mremove. Maybe,
there is a better way?
Did you "remove" or "svn remove"? Same for "rename". I guess you did
"svn [remove|rename]", and some other people did not "make distclean"
before "svn up". FWIW, I had no problems with your changes, doing
"make distclean" before "svn up".
Whoever compiles GRASS from source and wants the latest and greatest
(svn up), must clean the source code first with "make distclean"
before recompiling. This applies to all 4 branches. This is not GRASS
specific but the way how svn works.
On Wed, Oct 01, 2014 at 10:43:54PM +0200, Markus Metz wrote:
On Tue, Sep 30, 2014 at 8:16 PM, Huidae Cho <grass4u@gmail.com> wrote:
> Hmm... I "remove"d g.list/g.remove and "rename"d g.mlist/g.mremove. Maybe,
> there is a better way?
Did you "remove" or "svn remove"? Same for "rename". I guess you did
"svn [remove|rename]", and some other people did not "make distclean"
before "svn up". FWIW, I had no problems with your changes, doing
"make distclean" before "svn up".
Yes, I did "svn remove" and "svn rename". Of course, I had to "make
distclean". IMHO, "svn up" before "make distclean" shouldn't affect
compilation because "make distclean" has nothing to do with the svn
repository, but "make distclean" is necessary after or before "svn up"
anyway.
Regards,
Huidae
Whoever compiles GRASS from source and wants the latest and greatest
(svn up), must clean the source code first with "make distclean"
before recompiling. This applies to all 4 branches. This is not GRASS
specific but the way how svn works.
Markus M
>
> On Tue, Sep 30, 2014 at 1:19 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
>>
>>
>>
>> On Tue, Sep 30, 2014 at 12:02 PM, Markus Neteler <neteler@osgeo.org>
>> wrote:
>>>
>>> On Tue, Sep 30, 2014 at 5:25 PM, Vaclav Petras <wenzeslaus@gmail.com>
>>> wrote:
>>> ...
>>> > Confirmed, I had to do the same in all copies too some time ago. SVN is
>>> > not
>>> > really good at renaming and deleting things, it is always confused and
>>> > I
>>> > really don't understand why I need to do revert.
>>>
>>> As this almost never happened, it may have been this specific commit
>>> being different from others.
>>> Whatever, the solution we have.
>>>
>> Oh, now I hope it was not because I recommended some Git-like procedure to
>> Huidae which is not really what SVN wanted. Anyway, it was easy to solve
>> although it required manual intervention to automatic builds (at least the
>> one for tests).
>>
>>
>>>
>>> Markus
>>
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
On Wed, Oct 01, 2014 at 05:49:08PM -0400, Vaclav Petras wrote:
On Wed, Oct 1, 2014 at 4:43 PM, Markus Metz
<[1]markus.metz.giswork@gmail.com> wrote:
On Tue, Sep 30, 2014 at 8:16 PM, Huidae Cho <[2]grass4u@gmail.com>
wrote:
> Hmm... I "remove"d g.list/g.remove and "rename"d
g.mlist/g.mremove. Maybe,
> there is a better way?
Did you "remove" or "svn remove"? Same for "rename". I guess you did
"svn [remove|rename]", and some other people did not "make
distclean"
before "svn up". FWIW, I had no problems with your changes, doing
"make distclean" before "svn up".
Whoever compiles GRASS from source and wants the latest and greatest
(svn up), must clean the source code first with "make distclean"
before recompiling. This applies to all 4 branches. This is not
GRASS
specific but the way how svn works.
make distclean or just make clean, this might be it. The message from
SVN was not much helpful, although it changed from the previous
version.
But usually you don't have to do make *clean, so how to know these
things ahead (except for looking at Trac)? I don't know. Or is there
some option in SVN (from the options you are given) to use "theirs all"
as it was in previous SVN version (I don't know which)?
I guess that when you "svn up", it doesn't clean the OBJ directory in
the old g.list/g.remove directories and old object files conflict with
the new source files?
Huidae
Markus M
>
> On Tue, Sep 30, 2014 at 1:19 PM, Vaclav Petras
<[3]wenzeslaus@gmail.com> wrote:
>>
>>
>>
>> On Tue, Sep 30, 2014 at 12:02 PM, Markus Neteler
<[4]neteler@osgeo.org>
>> wrote:
>>>
>>> On Tue, Sep 30, 2014 at 5:25 PM, Vaclav Petras
<[5]wenzeslaus@gmail.com>
>>> wrote:
>>> ...
>>> > Confirmed, I had to do the same in all copies too some time ago.
SVN is
>>> > not
>>> > really good at renaming and deleting things, it is always
confused and
>>> > I
>>> > really don't understand why I need to do revert.
>>>
>>> As this almost never happened, it may have been this specific
commit
>>> being different from others.
>>> Whatever, the solution we have.
>>>
>> Oh, now I hope it was not because I recommended some Git-like
procedure to
>> Huidae which is not really what SVN wanted. Anyway, it was easy to
solve
>> although it required manual intervention to automatic builds (at
least the
>> one for tests).
>>
>>
>>>
>>> Markus
>>
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> [6]grass-dev@lists.osgeo.org
>> [7]http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> _______________________________________________
> grass-dev mailing list
> [8]grass-dev@lists.osgeo.org
> [9]http://lists.osgeo.org/mailman/listinfo/grass-dev
On Thu, Oct 2, 2014 at 4:22 PM, Huidae Cho <grass4u@gmail.com> wrote:
On Wed, Oct 01, 2014 at 05:49:08PM -0400, Vaclav Petras wrote:
On Wed, Oct 1, 2014 at 4:43 PM, Markus Metz
<[1]markus.metz.giswork@gmail.com> wrote:
On Tue, Sep 30, 2014 at 8:16 PM, Huidae Cho <[2]grass4u@gmail.com>
wrote:
> Hmm... I "remove"d g.list/g.remove and "rename"d
g.mlist/g.mremove. Maybe,
> there is a better way?
Did you "remove" or "svn remove"? Same for "rename". I guess you did
"svn [remove|rename]", and some other people did not "make
distclean"
before "svn up". FWIW, I had no problems with your changes, doing
"make distclean" before "svn up".
Whoever compiles GRASS from source and wants the latest and greatest
(svn up), must clean the source code first with "make distclean"
before recompiling. This applies to all 4 branches. This is not
GRASS
specific but the way how svn works.
make distclean or just make clean, this might be it. The message from
SVN was not much helpful, although it changed from the previous
version.
But usually you don't have to do make *clean, so how to know these
things ahead (except for looking at Trac)? I don't know. Or is there
some option in SVN (from the options you are given) to use "theirs all"
as it was in previous SVN version (I don't know which)?
I guess that when you "svn up", it doesn't clean the OBJ directory in
the old g.list/g.remove directories and old object files conflict with
the new source files?
Exactly.
The OBJ directory is not under version control, so svn does not touch
it. That means, svn up can not remove a directory if it contains
anything not under version control, and this can lead to conflicts.
Whoever compiles GRASS from source and wants the latest and greatest
(svn up), must clean the source code first with "make distclean"
before updating with svn up. This applies to all 4 branches. This is
not GRASS specific but the way how svn works. I did this on different
systems with different svn clients and had no problems.
Markus M
Huidae
Markus M
>
> On Tue, Sep 30, 2014 at 1:19 PM, Vaclav Petras
<[3]wenzeslaus@gmail.com> wrote:
>>
>>
>>
>> On Tue, Sep 30, 2014 at 12:02 PM, Markus Neteler
<[4]neteler@osgeo.org>
>> wrote:
>>>
>>> On Tue, Sep 30, 2014 at 5:25 PM, Vaclav Petras
<[5]wenzeslaus@gmail.com>
>>> wrote:
>>> ...
>>> > Confirmed, I had to do the same in all copies too some time ago.
SVN is
>>> > not
>>> > really good at renaming and deleting things, it is always
confused and
>>> > I
>>> > really don't understand why I need to do revert.
>>>
>>> As this almost never happened, it may have been this specific
commit
>>> being different from others.
>>> Whatever, the solution we have.
>>>
>> Oh, now I hope it was not because I recommended some Git-like
procedure to
>> Huidae which is not really what SVN wanted. Anyway, it was easy to
solve
>> although it required manual intervention to automatic builds (at
least the
>> one for tests).
>>
>>
>>>
>>> Markus
>>
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> [6]grass-dev@lists.osgeo.org
>> [7]http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> _______________________________________________
> grass-dev mailing list
> [8]grass-dev@lists.osgeo.org
> [9]http://lists.osgeo.org/mailman/listinfo/grass-dev
However, it needs to be manually fixed in all SVN