On Tue, 2010-05-11, Peter Kahn wrote:
> Thanks I have read that doc, but it was a while back so I'll re read
> it.
>
> The issue with the problems we are seeing is that I'm coming in late
> to this situation so most o of these I haven't seen first hand. I
> also discovered that people weren't us
Thanks, I am not entirely sure what people were using for their push / pull
but I'm pushing a standard now.
I think we hit the following problems that made things worse:
- cherry pick merges + merges at levels below root (all are allowed, but
they can make later merges more complex)
- we assumed m
Thanks I have read that doc, but it was a while back so I'll re read it.
The issue with the problems we are seeing is that I'm coming in late to this
situation so most o of these I haven't seen first hand. I also discovered
that people weren't using --reintegrate and push from branch to trunk.
T
Stefan Sperling writes:
> Blindly marking all delete vs. delete conflicts resolved is wrong
> (unless you don't care about rename conflicts).
As I said, it's debatable. One could decide that since renames don't
exist they really are just copies and deletes. In that case the
deletes don't confl
On Tue, May 11, 2010 at 03:53:20PM +0100, Philip Martin wrote:
> (4) This is deliberate Subversion policy as Subversion cannot
> distinguish between simple deletes and deletes that are part of a
> move. It's debatable whether this behaviour is correct, but it is
> deliberate.
This is a problem wi
Peter Kahn writes:
> *Problems we are seeing:*
>
>1. changes not reported during trunk-to-branch merge show up in
>subsequent branch-to-trunk
>2. conflicts on svn:mergefinfo properties during merge
>3. file missing, but local edit on new file added in branch and pushed to
>tru
On Mon, May 10, 2010 at 12:12:49PM -0400, Peter Kahn wrote:
> People use the this merge pattern
>
> a) PULL - merge trunk-to-branch, resolve, test, commit
>
> b) PUSH - merge branch-to-trunk, resolve, test, commit
>
> c) Recreate branch (or usually create new story branch and drop old since
> it
Hi Peter.
The mergeinfo "corruption" may be real, but just as likely it doesn't
work the way you expect, or Subversion is being asked to perform
combinations of merging that it doesn't support automatically. It seems
likely that even if there is some "corrupt" merge info, that is only a
part of t
I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know
how I'd make a determination and what resources are out there to help
fix problems?
I'd make the determination by reading and understanding the mergeinfo
values. They are plain text after all. The resource to read is
http:
I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know how
I'd make a determination and what resources are out there to help fix
problems?
Here’s the issue. My team recently moved to agile and uses feature branches
(story branches really) where different teams work on the same sour
10 matches
Mail list logo
