Merging from new Trunk question

[Z W]

Hi All

We have been merging from trunk A to branch B; recently another branch C is
created out of trunk A; trunk A is frozen and C has become the new trunk
for us;

1- will the mergeinfo in Trunk A be copied over to Trunk C so that we can
continue merging from Trunk C to branch B
2- would be there issues with merging back from Branch B to Trunk C ?

Thanks
Sincerely

mergeinfo deleted and how to recover ?

[Z W]

Hi All

We have been merging from trunk A to branch B; recently another branch C is
created out of trunk A; trunk A is frozen and C has become the new trunk
for us;

We mistakenly co the trunk C and performed
svn propdel svn:mergeinfo -R
svn revert .
svn commit -m "should not have done it"

Now when we perform
svn mergeinfo --show-revs merged http://some.url.com/trunk/C

and

svn mergeinfo --show-revs eligible http://some.url.com/trunk/C

all the revision numbers that were shown after performing merging from
Trunk A to branch B are no longer reflected in the lists of TrunkB-Branch B.

In other words, all
revision numbers in TrunkA-mergedTo-BranchB
are not reflected/shown in
TrunkC-mergedTo-BranchB

Are we in trouble ?
How do we revert back ?

Thanks




1- will the mergeinfo in Trunk A be copied over to Trunk C so that we can
continue merging from Trunk C to branch B
2- would be there issues with merging back from Branch B to Trunk C ?

Re: mergeinfo deleted and how to recover ?

[Johan Corveleyn]

On Mon, May 6, 2013 at 10:59 PM, Z W  wrote:
> Hi All
>
> We have been merging from trunk A to branch B; recently another branch C is
> created out of trunk A; trunk A is frozen and C has become the new trunk for
> us;
>
> We mistakenly co the trunk C and performed
> svn propdel svn:mergeinfo -R
> svn revert .
> svn commit -m "should not have done it"
>
> Now when we perform
> svn mergeinfo --show-revs merged http://some.url.com/trunk/C
>
> and
>
> svn mergeinfo --show-revs eligible http://some.url.com/trunk/C

Not sure if I fully understand your description. Are you running these
commands while still in the working copy of trunkC? Because 'svn
mergeinfo' normally takes both a source (URL) and a target, and if
target is not given, '.' is assumed.

> all the revision numbers that were shown after performing merging from Trunk
> A to branch B are no longer reflected in the lists of TrunkB-Branch B.
>
> In other words, all
> revision numbers in TrunkA-mergedTo-BranchB
> are not reflected/shown in
> TrunkC-mergedTo-BranchB

Well, it's possible that this is normal behavior given svn's current
design. Have you checked what those commands showed before you deleted
the subtree mergeinfo? Maybe they already showed nothing?

I really don't know if what you're trying to do will work. I'm not
sure that svn understands that trunkC is just the continuation of
trunkA, but under a new name. How can it tell the difference between
"just another branch of trunkA", and "a new trunk, with a new name"?
Now, perhaps that distinction doesn't really matter: in theory svn
should just as well be able to merge (and reintegrate) between two
branches, and perhaps know that some changes were already merged
before the second branch came into existence. But in practice? I don't
know. Maybe someone else on this list knows?

In the absence of definitive answers I have two suggestions:

- Try some local experiments. You should be able to test quite some
things without committing (just merging or reintegrating to a clean
checkout of X, Y, Z ... and verify the result in your working copy).

- The upcoming 1.8 release contains some improvements in this area
(see [1]). If 1.7 doesn't work for you, perhaps give 1.8 (RC 1) a try?
The first release candidate will soon be available.

> Are we in trouble ?
> How do we revert back ?

That's easy, just undo that revision: [2].

> Thanks
>
>
>
>
> 1- will the mergeinfo in Trunk A be copied over to Trunk C so that we can
> continue merging from Trunk C to branch B

The mergeinfo will be copied along from trunkA to trunkC, just like
anything else (files, properties, ...). Feel free to check for
yourself.

However, as said above, I'm not sure you can continue merging from
trunkC to branchB, acting just like nothing happened. The problem is
that branchB's mergeinfo literally contains "trunkA" in its
description. If you look at the svn:mergeinfo property, you'll see
things like "/trunkA:345-456" (meaning: revisions 345 til 456 were
merged from trunkA). I'm not sure if svn is smart enough to realize
that these merges also apply to trunkC's relation with branchB, since
those trunkA-revs are part of trunkC's natural history. Best to try
some experiments to find out.

> 2- would be there issues with merging back from Branch B to Trunk C ?

Same as above ... not sure.


[1] http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
[2] 
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

--
Johan

trunk naming best practice question

[Z W]

Hi All

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 branch name
would be while at the same time, we need to perform daily builds for QA
testing.

What's the best practice in use with SVN ?

Thanks
Sincerely

Re: trunk naming best practice question

[Geoff Hoffman]

It's common to have

yourrepo
   /branches
   /tags
   /trunk

Each day, tag the trunk (svn copy) as /tags/ and build that in your
CI tool and push it to your testing server.

Branches are typically feature-related or release-related, e.g.
/branches/feature-name or /branches/development or /branches/v2.0alpha.
I've also seen it work where each developer has his/her own branch -
/branches/yourname /branches/hername.

Does that give you some ideas?





Geoff Hoffman
Solutions Architect & LAMP Engineer
phone +1 623.399.4918
mobile +1 480.231.8323
web CardinalPath.com 



On Mon, May 6, 2013 at 8:50 PM, Z W  wrote:

> Hi All
>
> 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 branch name
> would be while at the same time, we need to perform daily builds for QA
> testing.
>
> What's the best practice in use with SVN ?
>
> Thanks
> Sincerely
>

-- 


Connect with us on twitter , 
google+
, facebook , or 
linkedin
.

Catch our next training in Washington May 
6-10
, Los Angeles May 13 - 
17
, Boston May 20 - 
24
, Ottawa May 
27-31
 or See 
All
.

This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: trunk naming best practice question

[Z W]

Hi Geoff

Thanks for responding.
So one would not make builds on trunk directly ?

Thanks again


On Mon, May 6, 2013 at 9:18 PM, Geoff Hoffman wrote:

> It's common to have
>
> yourrepo
>/branches
>/tags
>/trunk
>
> Each day, tag the trunk (svn copy) as /tags/ and build that in your
> CI tool and push it to your testing server.
>
> Branches are typically feature-related or release-related, e.g.
> /branches/feature-name or /branches/development or /branches/v2.0alpha.
> I've also seen it work where each developer has his/her own branch -
> /branches/yourname /branches/hername.
>
> Does that give you some ideas?
>
>
>
>
>
> Geoff Hoffman
> Solutions Architect & LAMP Engineer
> phone +1 623.399.4918
> mobile +1 480.231.8323
> web CardinalPath.com 
>
>
>
> On Mon, May 6, 2013 at 8:50 PM, Z W  wrote:
>
>> Hi All
>>
>> 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 branch name
>> would be while at the same time, we need to perform daily builds for QA
>> testing.
>>
>> What's the best practice in use with SVN ?
>>
>> Thanks
>> Sincerely
>>
>
>
> Connect with us on twitter , 
> google+
> , facebook ,** or 
> linkedin
> .
>
> Catch our next training in Washington May 
> 6-10
> , Los Angeles May 13 - 
> 17
> , Boston May 20 - 
> 24
> , Ottawa May 
> 27-31
>  or See 
> All
> .
>
> This email, including any attachments, is for the sole use of the intended
> recipient and may contain confidential information. If you are not the
> intended recipient, please immediately notify us by reply email or by
> telephone, delete this email and destroy any copies. Thank you.
>
>