> From: Z W [mailto:mpc8...@gmail.com]
> Sent: Tuesday, May 07, 2013 11:53 AM
> To: users@subversion.apache.org
> Subject: mergeinfo between svn copied branches and merges
>
> we have branchA
> we svn copy branchA to produce branchB
> branches A and B continues development and checkins
> branchA
Hi All
we have branchA
we svn copy branchA to produce branchB
branches A and B continues development and checkins
branchA is merged to branch B continuously
branchA finishes, tagged
we then svn copy branchA to produce branchC
we like to continue branchC merging to branchB
we hear u clearly
> For the trunk, what's the common practice to name a version of the trunk?
> We have a trunk and it's not ready for branching.
> We also feel that we need a more specific name for the trunk than what we
> have now called version=trunk.
> However, we can't be specific since we don't know what the b
On Tue, May 7, 2013 at 12:14 AM, Z W wrote:
> Hi Geoff
>
> Thanks for responding.
> So one would not make builds on trunk directly ?
That would depend partly on your tools and workflow. Daily tags are
good for providing a more human-friendly reference name to pass
between developers and QA if bu
Guten Tag Z W,
am Dienstag, 7. Mai 2013 um 09:15 schrieben Sie:
> Suppose trunk has been merging to branch. would renaming a trunk
> (trunk name change) causes an automatic change in the svn:mergeinfo
> of a branch[...]
No, Subversion doesn't magically generates "changes" in your working
copy to
Hi All
Suppose trunk has been merging to branch. would renaming a trunk (trunk
name change) causes an automatic change in the svn:mergeinfo of a branch so
that merged mergeinfo list and eligible merge info list remains intact
(from the branch perspective) ?
Then when branch needs to reintegrate t
