> --
> From: "Bob Archer"
> Sent: Thursday, April 21, 2011 11:17 AM
> To: "Daniel Walter" ; "Stefan Sperling"
>
> Cc:
> Subject: RE: duplicate merge conflict
>
> >> >> Reco
--
From: "Bob Archer"
Sent: Thursday, April 21, 2011 11:17 AM
To: "Daniel Walter" ; "Stefan Sperling"
Cc:
Subject: RE: duplicate merge conflict
>> Record only should only make changes to the properties and
> >> Record only should only make changes to the properties and not
> the files.
> >> You can also just manually update the svn:merginfo on the trunk
> if you
> >> want.
> >
> > I think the problem is that because Daniel is using ancestrally
> > unrelated trees for the left and right side of his me
Record only should only make changes to the properties and not the files.
You can also just manually update the svn:merginfo on the trunk if you
want.
I think the problem is that because Daniel is using ancestrally
unrelated trees for the left and right side of his merge diff there
is no merge-
On Wed, Apr 20, 2011 at 04:32:54PM -0400, Bob Archer wrote:
> > 2. I just tried the above command and it started trying to merge
> > things from
> > months ago together. Is there any way to tell SVN what it should
> > use as a
> > baseline for automatic merges? I tried tried just letting it
> > f
> > Like I said, we don't even have a path named "trunk".
> >
> > The paths to the above versions in the repo would be like:
> >
> > svn://server/repo/project/v1.0.0
> > svn://server/repo/project/v1.0.1 (this was copied from the 1.0.0
> path)
> > svn://server/repo/project/v1.0.2 (this was copied
Like I said, we don't even have a path named "trunk".
The paths to the above versions in the repo would be like:
svn://server/repo/project/v1.0.0
svn://server/repo/project/v1.0.1 (this was copied from the 1.0.0 path)
svn://server/repo/project/v1.0.2 (this was copied from the 1.0.1 path)
On my
> > If you are merging everything in there is no need to worry. That
> is the
> > point of merge tracking. It will determine what has yet to be
> merged and
> > select the correct revisions.
> >
> > Here is how we have our repo set up... rather than using trunk.
> We find it
> > makes things easier
On Wed, Apr 20, 2011 at 10:05:08AM -0400, Daniel Walter wrote:
> >4.1.x-release +LR--
> > / | +--- 4.3.x-release
> > / | /
> >/ |
If you are merging everything in there is no need to worry. That is the
point of merge tracking. It will determine what has yet to be merged and
select the correct revisions.
Here is how we have our repo set up... rather than using trunk. We find it
makes things easier.
We basically "branch"
> > On Tue, Apr 19, 2011 at 09:34:17PM -0400, Daniel Walter wrote:
> >> I understand what is going on now, but this seems to indicate
> that I
> >> will need to look up revision numbers from tags every time I do
> a
> >> merge in SVN. Is there any automated way of doing this? It
> seems
> >> like
--
From: "Stefan Sperling"
Sent: Wednesday, April 20, 2011 6:38 AM
To: "Daniel Walter"
Cc: "Bob Archer" ;
Subject: Re: duplicate merge conflict
On Tue, Apr 19, 2011 at 09:34:17PM -0400, Daniel Walter wrote:
I u
On Tue, Apr 19, 2011 at 09:34:17PM -0400, Daniel Walter wrote:
> I understand what is going on now, but this seems to indicate that I
> will need to look up revision numbers from tags every time I do a
> merge in SVN. Is there any automated way of doing this? It seems
> like a huge step backwards
t: Tuesday, April 19, 2011 6:50 PM
To: "Daniel Walter"
Cc: "Bob Archer" ;
Subject: Re: duplicate merge conflict
On Tue, Apr 19, 2011 at 10:56:28AM -0400, Daniel Walter wrote:
svn merge appears to work with revision numbers but not symbolically
with tags. Is this expected?
Th
On Tue, Apr 19, 2011 at 10:56:28AM -0400, Daniel Walter wrote:
> svn merge appears to work with revision numbers but not symbolically
> with tags. Is this expected?
>
> The merge happens twice if I use tags:
> svn merge tag1 tag2 --non-interactive
>
> But when I find the revisions with svn info
On Apr 19, 2011, at 09:56, Daniel Walter wrote:
> svn merge appears to work with revision numbers but not symbolically with
> tags. Is this expected?
Tags are not symbols. Tags are directories. You can merge with directories if
you want, provided you use their complete repository URL, or a val
RE: duplicate merge conflict
--
From: "Bob Archer"
Sent: Thursday, April 14, 2011 9:33 AM
To: "Daniel Walter" ;
Subject: RE: duplicate merge conflict
>> When I merge changes in SVN, the merges work well except for the
would be the last commit before the svn
copy and 462 is the svn copy itself.
--
From: "Bob Archer"
Sent: Thursday, April 14, 2011 1:38 PM
To: "Daniel Walter" ;
Subject: RE: dupl
> --
> From: "Bob Archer"
> Sent: Thursday, April 14, 2011 9:33 AM
> To: "Daniel Walter" ;
>
> Subject: RE: duplicate merge conflict
>
> >> When I merge changes in SVN, the merges work well ex
o: "Daniel Walter" ;
Subject: RE: duplicate merge conflict
When I merge changes in SVN, the merges work well except for the
conflicts. For some reason, the merges are frequently (but not
always done twice). As an example:
<<<<<<< .working
<<<<<
> When I merge changes in SVN, the merges work well except for the
> conflicts. For some reason, the merges are frequently (but not
> always done twice). As an example:
> <<< .working
> <<< .working
> const int SERIALIZE_FIELDS_DATA_LENGTH = 83;
> ===
> const int SERIALIZE_FIELDS_DATA
When I merge changes in SVN, the merges work well except for the conflicts.
For some reason, the merges are frequently (but not always done twice). As an
example:
<<< .working
<<< .working
const int SERIALIZE_FIELDS_DATA_LENGTH = 83;
===
const int SERIALIZE_FIELDS_DATA_LENGTH = 91;
22 matches
Mail list logo
