On Jul 18, 2016, at 9:49, Andreas Stieger wrote:
> I wrote nothing of GUI.
Doh! I just saw the “UI” in capital letters and complete missed the “cli” in
lower case that preceded it - sorry about that! Anyway, I’m no closer in
resolving this merge issue, but will attempt to merge the revisions
Hello,
> > Ideally use svn cli UI only.
>
> Really? I’ve had better luck using the CLI for merges. So what GUI do you
> recommend using on Linux?
I wrote nothing of GUI.
Andreas
On Jul 18, 2016, at 3:00, Andreas Stieger wrote:
> Commonly caused by explicit subtree mergeinfo. Check for svn:mergeinfo
> properties set on subtrees for both the merge source and the merge target.
Unfortunately that’s not the case here. While there was one svn:mergeinfo
property in a subtre
> $ svn pg svn:mergeinfo | grep branchA
> /branches/branchA:28000-29203
> $ svn pe svn:mergeinfo .
> Set new value for property 'svn:mergeinfo' on '.'
> $ svn pg svn:mergeinfo | grep branchA
> /branches/branchA:15542-29203
> $ svn mergeinfo ^/branches/branchA --show-revs=eligible
> [100’s of revi
So is it me or is there something broken here? A quick recap:
$ svn pg svn:mergeinfo | grep branchA
/branches/branchA:28000-29203
$ svn pe svn:mergeinfo .
Set new value for property 'svn:mergeinfo' on '.'
$ svn pg svn:mergeinfo | grep branchA
/branches/branchA:15542-29203
$ svn mergeinfo ^/branch
On Jul 15, 2016, at 3:02, Stefan Sperling wrote:
> I'm afraid it's not obvious to me what issue you are referring to.
>
> Which behaviour are you expecting, and how does Subversion not meet
> your expectations?
I expect Subversion to merge only revisions 29203:HEAD of branchA into
branchB. Why
On Thu, Jul 14, 2016 at 09:38:05PM -0400, Alfred von Campe wrote:
> A user at work came to me with a strange merge issue and I have been able to
> reproduce it. This happens with both a 1.8.16 and 1.9.4 Linux CLI client. I
> usually can resolve these merge issues by deleting superfluous svn:mer
A user at work came to me with a strange merge issue and I have been able to
reproduce it. This happens with both a 1.8.16 and 1.9.4 Linux CLI client. I
usually can resolve these merge issues by deleting superfluous svn:mergeinfo
properties in subdirectories and/or by editing the svn:mergeinfo
M
To: John Maher
Cc: Subversion help
Subject: Re: Merge problem
On Thu, Sep 11, 2014 at 11:56:22AM +, John Maher wrote:
> Thanks for your reply Stefan. There are no subdirs on either my trunk or
> branches. The command I used was (from the working copy of (for example)
> https://server
On Thu, Sep 11, 2014 at 12:03:36PM +, Markus Schaber wrote:
> Hi, John,
>
> I guess Stefans question for more details was directed to Andreas and his
> rather unspecific rant, not to your email.
Correct :)
runk with 'svn log' to see how they came into existence?
>
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: Wednesday, September 10, 2014 4:24 AM
> To: John Maher
> Cc: Subversion help
> Subject: Re: Merge problem
>
>
ing; Andreas Tscharner
> Cc: Subversion help
> Betreff: RE: Merge problem
>
> I sent lots of details. If you can't see them then perhaps something is
> buggy with the help system. The conflicts were either "local add, incoming
> add upon merge" or " local dele
...@elego.de]
Sent: Wednesday, September 10, 2014 4:24 AM
To: John Maher
Cc: Subversion help
Subject: Re: Merge problem
On Tue, Sep 09, 2014 at 06:48:31PM +, John Maher wrote:
> Hello
>
> Just wondering if anyone may have an idea how my repository got so buggered
> up. I tried to me
ilto:s...@elego.de]
Sent: Wednesday, September 10, 2014 7:32 AM
To: Andreas Tscharner
Cc: John Maher; Subversion help
Subject: Re: Merge problem
On Wed, Sep 10, 2014 at 10:56:42AM +, Andreas Tscharner wrote:
>
> [snip]
> > Just wondering if anyone may have an idea how my repository
On Wed, Sep 10, 2014 at 10:56:42AM +, Andreas Tscharner wrote:
>
> [snip]
> > Just wondering if anyone may have an idea how my repository
> > got so buggered up. I tried to merge a branch to the trunk
> > and received 49 conflicts. 2 are files that do not need to
> > be tracked so that le
[snip]
> Just wondering if anyone may have an idea how my repository
> got so buggered up. I tried to merge a branch to the trunk
> and received 49 conflicts. 2 are files that do not need to
> be tracked so that leaves 47. Out of the 47 there are two
> problems, local add, incoming add upon
On Tue, Sep 09, 2014 at 06:48:31PM +, John Maher wrote:
> Hello
>
> Just wondering if anyone may have an idea how my repository got so buggered
> up. I tried to merge a branch to the trunk and received 49 conflicts. 2 are
> files that do not need to be tracked so that leaves 47. Out of th
Hello
Just wondering if anyone may have an idea how my repository got so buggered up.
I tried to merge a branch to the trunk and received 49 conflicts. 2 are files
that do not need to be tracked so that leaves 47. Out of the 47 there are two
problems, local add, incoming add upon merge & loc
On Sat, Nov 12, 2011 at 06:53:54PM +0100, Gunnar Dalsnes wrote:
> On 11.11.2011 16:51, Philip Martin wrote:
> >You can't revert wc/D/f without reverting the replace of wc/D.
> Does this mean it's not possible to merge if the same dir is created
> both in trunk and in branch? Can the "replace" of th
On 11.11.2011 16:51, Philip Martin wrote:
You can't revert wc/D/f without reverting the replace of wc/D.
Does this mean it's not possible to merge if the same dir is created
both in trunk and in branch? Can the "replace" of the "duplicate" dir be
avoided somehow? If not, it would be nice with a
Philip Martin writes:
> The merge creates an added directory wc/D (copied from /T/D in the
> repo). This conflicts with the directory D added by the update (which
> is /X/B in the repo) so a tree conflict is created. Note that wc/D is
Typo: /X/B should be /B/D.
> marked as replaced.
--
Phili
Gunnar Dalsnes writes:
>>>
>>> REM tree conflict
>>>
>>> svn resolve --accept=working dir1
>> Did you miss a step?
> No, nothing is missed, but it seems this line is useless (but
> harmless). The problem appears regardless.
>> trunk2 is still an empty directory at r1, how can
>> that cause a co
I can make a Linux script if that will help...
On 10.11.2011 17:17, Gunnar Dalsnes wrote:
On 10.11.2011 12:26, Philip Martin wrote:
Gunnar Dalsnes writes:
REM change this to the dir you are running the script from
set wd=c:/temp/test
svnadmin create repo
svn mkdir file:///%wd%/repo/trunk -
On 10.11.2011 12:26, Philip Martin wrote:
Gunnar Dalsnes writes:
REM change this to the dir you are running the script from
set wd=c:/temp/test
svnadmin create repo
svn mkdir file:///%wd%/repo/trunk -m test
svn co file:///%wd%/repo/trunk trunk1
svn co file:///%wd%/repo/trunk trunk2
trunk2
Gunnar Dalsnes writes:
> REM change this to the dir you are running the script from
> set wd=c:/temp/test
>
> svnadmin create repo
>
> svn mkdir file:///%wd%/repo/trunk -m test
>
> svn co file:///%wd%/repo/trunk trunk1
> svn co file:///%wd%/repo/trunk trunk2
trunk2 is an empty directory at r1
>
Hi,
Think I found a problem with svn 1.7.1 on Windows, where after a merge
and a tree conflict (annoying, since both dirs have same name), I ended
up with a file with status deleted (for unknown reason), and it seems
impossible to revert (undelete) this file.
I made a batch script where I be
e.org; Strucken, Andreas
Subject: Re: Merge problem with different users
On Mon, Sep 06, 2010 at 02:44:30AM -0700, Ungruhe, Michael wrote:
> The "merge user" is just a user account. Since we noticed that the
> problem described earlier only occurs when the merging is made by
>
On Mon, Sep 06, 2010 at 02:44:30AM -0700, Ungruhe, Michael wrote:
> The "merge user" is just a user account. Since we noticed that the
> problem described earlier only occurs when the merging is made by
> different users (on different user accounts), we created a new user
> account (called mergeuse
the users itself are still different, but they use
the same account.
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Freitag, 3. September 2010 11:08
To: Ungruhe, Michael
Cc: users@subversion.apache.org; Strucken, Andreas
Subject: Re: Merge problem with different use
On Fri, Sep 03, 2010 at 12:53:34AM -0700, Ungruhe, Michael wrote:
> Hi,
>
>
>
> We noticed the following problem:
>
>
>
> We are usually working on the trunk, but for a change request we created a
> branch. Development continued on both, the trunk and the branch.
>
> Some changes were ma
Hi,
We noticed the following problem:
We are usually working on the trunk, but for a change request we created a
branch. Development continued on both, the trunk and the branch.
Some changes were made on the trunk including the deletion of some files, all
changes were committed to the t
31 matches
Mail list logo
