RE: Merge, reintegrate, and merge with tree conflicts
So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. You can keep the feature branch alive by doing a record only merge on the trunk of the revision which your integrate merge was committed as. BOb On Feb 22, 2013, at 7:22 PM, Matthew Pounsett m...@conundrum.com wrote: On 2013/02/22, at 14:15, James Hanley wrote: We are seeing merge tree conflicts where I believe svn is not working as expected. I'm not entirely sure if this is due to a lack of understanding for proper use on our part, but it was my understanding that reintegrate was to be used when pulling changes from a branch and pushing them into the copied from branch. I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way: cd branches svn cp ^/trunk ./mybranch cd mybranch mkdir foo svn add foo svn commit -m added foo to mybranch cd ../../trunk svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch svn merge ^/trunk As soon as the --reintegrate is done, ^/branches/mybranch is dead. [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox /%3C01A9EBD6-CE2D-4565-833D-2252CE2E5B71%40conundrum.com%3E [2] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox /%3C20130207150922.GC28403%40ted.stsp.name%3E
RE: Merge, reintegrate, and merge with tree conflicts
So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. You can keep the feature branch alive by doing a record only merge on the trunk of the revision which your integrate merge was committed as. Sorry, this should say: You can keep the feature branch alive by doing a record only merge on the branch from trunk of the revision which your integrate merge was committed as. BOb BOb On Feb 22, 2013, at 7:22 PM, Matthew Pounsett m...@conundrum.com wrote: On 2013/02/22, at 14:15, James Hanley wrote: We are seeing merge tree conflicts where I believe svn is not working as expected. I'm not entirely sure if this is due to a lack of understanding for proper use on our part, but it was my understanding that reintegrate was to be used when pulling changes from a branch and pushing them into the copied from branch. I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way: cd branches svn cp ^/trunk ./mybranch cd mybranch mkdir foo svn add foo svn commit -m added foo to mybranch cd ../../trunk svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch svn merge ^/trunk As soon as the --reintegrate is done, ^/branches/mybranch is dead. [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb ox /%3C01A9EBD6-CE2D-4565-833D- 2252CE2E5B71%40conundrum.com%3E [2] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb ox /%3C20130207150922.GC28403%40ted.stsp.name%3E
Re: Merge, reintegrate, and merge with tree conflicts
This is /really/ confusing as with the script I'm using reintegrate the first time to go from branch to trunk, but you're saying I also have to use it from trunk to branch - that is from origin to copied branch. I've read through Julian's post (repeatedly) and if I understand right, the reintegrate option will flip the perspective of the current merge and sync merges from then on... This seems /really/ accident prone as I'm still unclear as to with Julian's post what are the implications if there multiple branches off the originator involved, and multiple branch generations (branch of branch) involved - so refactoring what Julian wrote: Copy T-B1. Merge T-B1 -- use a sync merge Merge T-B1 -- use a sync merge Merge B1-T -- use a reintegrate merge Merge B1-T -- use a sync merge Merge B1-T -- use a sync merge Merge T-B1 -- use a reintegrate merge Merge T-B1 -- use a sync merge Copy T-B2 Merge T-B1 -- use a sync merge Merge T-B2 -- use a sync merge Merge B2-T -- use a reintegrate merge Merge T-B1 -- use a merge Copy B2-B2.1 Merge B2-B2.1 -- use a sync merge? Merge B2.1-B2 -- use a reintegrate merge? Merge B2-T -- use a ??? merge More merge shenanigans What about cherry picking such that a bug is fixed in the trunk and needs to be back-ported to a point release? If it's only available with automatic handling in 1.8, when will that be released (as http://subversion.apache.org/roadmap.html says Q4 2012 - /unconfirmed/) and we are over halfway through Q1 2013... For completeness sake, can you test if the reintegrate option is removed completely from the script, how does it perform against 1.8 - as I don't have a sandbox to test? On Sun, Feb 24, 2013 at 9:19 AM, Stefan Sperling s...@elego.de wrote: On Sun, Feb 24, 2013 at 07:57:14AM -0500, James Hanley wrote: I guess I should have read the next response in the thread before replying... So, to be clear (since you asked off-list): The following changes to your script prevent the tree conflict with 1.7. --- enduceTreeConflict.sh.orig Sun Feb 24 15:08:17 2013 +++ enduceTreeConflict.sh Sun Feb 24 15:08:29 2013 @@ -48,7 +48,7 @@ echo Rebaselining feature from trunk cd ../../branches/Program_rc1 svn up -svn merge ^/trunk/Program . +svn merge --reintegrate ^/trunk/Program . echo We have a tree conflict!!! #svn commit -m Rebaselining feature from trunk @@ -127,7 +127,7 @@ echo Perform additional downstream merging cd ../../usr/andy/Program_rc1_main_line svn up -svn merge ^/branches/int/Program_rc1 . +svn merge --reintegrate ^/branches/int/Program_rc1 . echo We have a tree conflict!!! svn status #svn commit -m Rebaselining usr/andy main line from integration main line Remember to use --reintegrate whenever you switch merge direction. The first time your script uses --reintegrate direction switches from trunk-branch to branch-trunk. The tree conflict happens when you switch direction again (to trunk-branch) but don't use --reintegrate. Having to keep track of which direction the prior merge was using is rather cumbersome, which is another reason why this feature is not widely advertised in existing documentation (besides the fact that is was discovered after 1.7 was released). Subversion 1.8 will fix this issue in a much nicer way. I've tried running your script with Subversion 1.8-to-be (i.e. trunk). There is no tree conflict at all, even without the above modifications, because Subversion 1.8 detects the changes of direction automatically.
Re: Merge, reintegrate, and merge with tree conflicts
On Mon, Feb 25, 2013 at 11:11:19AM -0500, James Hanley wrote: This is /really/ confusing as with the script I'm using reintegrate the first time to go from branch to trunk, but you're saying I also have to use it from trunk to branch - that is from origin to copied branch. I've read through Julian's post (repeatedly) and if I understand right, the reintegrate option will flip the perspective of the current merge and sync merges from then on... This seems /really/ accident prone Yes, it is very prone to accident, which is why it's not documented, as Julian himself pointed out in his post. The feature will officially be available in 1.8. Until then, you can use this trick or just ignore the fact that it exists if it confuses your users too much. It will be much easier once Subversion can figure out the correct merge direction on its own. I just mentioned it because of the claim that doing this was impossible with SVN, which isn't true. It's inconvenient at the moment, but not impossible. The inconvenience will be addressed in the next release. as I'm still unclear as to with Julian's post what are the implications if there multiple branches off the originator involved, and multiple branch generations (branch of branch) involved - so refactoring what Julian wrote: Copy T-B1. Merge T-B1 -- use a sync merge Merge T-B1 -- use a sync merge Merge B1-T -- use a reintegrate merge Merge B1-T -- use a sync merge Merge B1-T -- use a sync merge Merge T-B1 -- use a reintegrate merge Merge T-B1 -- use a sync merge Copy T-B2 Merge T-B1 -- use a sync merge Merge T-B2 -- use a sync merge Merge B2-T -- use a reintegrate merge Merge T-B1 -- use a merge I believe a sync merge would do here. The last direction in a merge from T to B1 was T-B1. That's what counts. B2 has nothing to do with it. Copy B2-B2.1 Merge B2-B2.1 -- use a sync merge? Merge B2.1-B2 -- use a reintegrate merge? Merge B2-T -- use a ??? merge Again, sync should be alright. The last merge involving B2 and T was in the B2-T direction. More merge shenanigans What about cherry picking such that a bug is fixed in the trunk and needs to be back-ported to a point release? I've already mentioned this briefly here: http://svn.haxx.se/users/archive-2013-02/0238.shtml Generally I would recommend to cherry-pick only to or from branches which never merge in their entirety with another branch. Say you have a release branch for all your 1.0.x releases. This branch will live as long as 1.0.x releases are shipping (1.0.0, 1.0.1, etc.), and then it will simply become uninteresting. You'd never attempt to merge this branch into a branch representing a different release (i.e. merge two code bases meant for different releases with one another in their entirety), and hence such a branch is suitable to be cherry-picked from and to. In particular, you want to avoid situations where cherry-picked changes end up being merged in a circular fashion, such as: initial commit on B1 - cherry-pick from B1 to B2 - merge B2 into T - merge T into B1 # initial change is applied again to B1 In this kind of situation, assuming both B1 and B2 are over time kept in sync with T, it is more appropriate to commit the change to T initially. It's a good idea to design your branching/merging strategy in a way that avoids cycles. There are many ways of doing so, so I cannot elaborate further without more information about your current strategy. If it's only available with automatic handling in 1.8, when will that be released (as http://subversion.apache.org/roadmap.html says Q4 2012 - /unconfirmed/) and we are over halfway through Q1 2013... When it's done. The community is already discussing the 1.8 release and is very eager to get it done. We're currently still applying some stability fixes for the new local-move-tracking feature. Follow the dev@ list if you're curious. If you'd like to help testing 1.8 once alpha and beta releases come out, that would be highly appreciated! Just watch this list or the announce@ list which receives much less traffic than the users@ list does. I believe there will be binary packages available for easy installation. For completeness sake, can you test if the reintegrate option is removed completely from the script, how does it perform against 1.8 - as I don't have a sandbox to test? Sure. Here's a transcript of a run of your script when run with 1.8 and all --reintegrate options removed. $ bash -x enduceTreeConflict.sh + svn --version svn, version 1.8.0-dev (under development) compiled Feb 25 2013, 10:54:05 on x86_64-unknown-openbsd5.3 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. -
RE: Merge, reintegrate, and merge with tree conflicts
So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. Short answer: There is none (with SVN) Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk). At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course) If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right? Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try. Best regards WENZEL Metromec AG Andreas Tscharner -- Andreas Tscharner, Development WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland phone: +41 (0)81 257 07 00 fax:+41 (0)81 257 07 01 e-mail: mailto:andreas.tschar...@metromec.ch www:http://www.metromec.ch
Re: Merge, reintegrate, and merge with tree conflicts
On Sun, Feb 24, 2013 at 12:14:04PM +, Andreas Tscharner wrote: So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. Short answer: There is none (with SVN) Sorry, not true :) Bidirectional merge is possible with SVN. Subversion 1.8 will ship with an enhanced 'automatic' merge that will make this very easy to do, see http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge But it is also possible with 1.7 -- it's just not widely documented because the trick for doing it was discovered fairly recently during 1.8 development, while the automatic merge feature was being developed. Quoting Julian Foad in http://svn.haxx.se/dev/archive-2012-05/0474.shtml * To merge again in the same direction as the previous merge = the existing sync merge will work. * To merge again in the opposite direction to the previous merge = the existing reintegrate merge will work. So whenever switching directions use --reintegrate, and then keep using plain 'svn merge' until you change directions again. See the rest of Julian's post for details. If you want to merge in this fashion, you should avoid subtree merges (e.g. merging ^/trunk/foo to ^/branches/branch/foo), but always merge all changes from the source branch (e.g. from ^/trunk to ^/branches/branch). You should also avoid cherry-picking merges, i.e. never specify a particular revision range to be merged, instead relying on merge-tracking to merge all outstanding changes. Note that both of the above restrictions exist in DVCS by design. So if you are already considering DVCS as an alternative these restrictions should not be an issue. Please let us know if this approach works well for you. Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk). At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course) If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right? Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try. Best regards WENZEL Metromec AG Andreas Tscharner -- Andreas Tscharner, Development WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland phone: +41 (0)81 257 07 00 fax:+41 (0)81 257 07 01 e-mail: mailto:andreas.tschar...@metromec.ch www:http://www.metromec.ch
Re: Merge, reintegrate, and merge with tree conflicts
Yes I have used git, etc - in the past, but we are forced to use svn for the time being. What I would like to quantify is if this shortcoming of subversion is by design or if its a bug. From your description, it seems like the former, and if so, what is the architectural reasoning? I understand the concept that the merge to WC records the merge information, and the merged from has no knowledge of the merge or even branch for that matter. Is this a use case that was taken into consideration, and will it be fixed or the functionality/logic added to allow this use case? Is there a tracker item or roadmap item describing such use, and what dependancies are blocking the implementation for this? On Feb 24, 2013, at 7:14 AM, Andreas Tscharner andreas.tschar...@metromec.ch wrote: So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. Short answer: There is none (with SVN) Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk). At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course) If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right? Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try. Best regards WENZEL Metromec AG Andreas Tscharner -- Andreas Tscharner, Development WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland phone: +41 (0)81 257 07 00 fax:+41 (0)81 257 07 01 e-mail: mailto:andreas.tschar...@metromec.ch www:http://www.metromec.ch
Re: Merge, reintegrate, and merge with tree conflicts
I guess I should have read the next response in the thread before replying... On Feb 24, 2013, at 7:52 AM, Stefan Sperling s...@elego.de wrote: On Sun, Feb 24, 2013 at 12:14:04PM +, Andreas Tscharner wrote: So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. Short answer: There is none (with SVN) Sorry, not true :) Bidirectional merge is possible with SVN. Subversion 1.8 will ship with an enhanced 'automatic' merge that will make this very easy to do, see http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge But it is also possible with 1.7 -- it's just not widely documented because the trick for doing it was discovered fairly recently during 1.8 development, while the automatic merge feature was being developed. Quoting Julian Foad in http://svn.haxx.se/dev/archive-2012-05/0474.shtml * To merge again in the same direction as the previous merge = the existing sync merge will work. * To merge again in the opposite direction to the previous merge = the existing reintegrate merge will work. So whenever switching directions use --reintegrate, and then keep using plain 'svn merge' until you change directions again. See the rest of Julian's post for details. If you want to merge in this fashion, you should avoid subtree merges (e.g. merging ^/trunk/foo to ^/branches/branch/foo), but always merge all changes from the source branch (e.g. from ^/trunk to ^/branches/branch). You should also avoid cherry-picking merges, i.e. never specify a particular revision range to be merged, instead relying on merge-tracking to merge all outstanding changes. Note that both of the above restrictions exist in DVCS by design. So if you are already considering DVCS as an alternative these restrictions should not be an issue. Please let us know if this approach works well for you. Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk). At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course) If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right? Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try. Best regards WENZEL Metromec AG Andreas Tscharner -- Andreas Tscharner, Development WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland phone: +41 (0)81 257 07 00 fax:+41 (0)81 257 07 01 e-mail: mailto:andreas.tschar...@metromec.ch www:http://www.metromec.ch
Re: Merge, reintegrate, and merge with tree conflicts
On Sun, Feb 24, 2013 at 07:55:41AM -0500, James Hanley wrote: Is this a use case that was taken into consideration, and will it be fixed or the functionality/logic added to allow this use case? See my other reply for more details, but yes, this is being addressed: http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
Re: Merge, reintegrate, and merge with tree conflicts
On Sun, Feb 24, 2013 at 07:57:14AM -0500, James Hanley wrote: I guess I should have read the next response in the thread before replying... So, to be clear (since you asked off-list): The following changes to your script prevent the tree conflict with 1.7. --- enduceTreeConflict.sh.orig Sun Feb 24 15:08:17 2013 +++ enduceTreeConflict.sh Sun Feb 24 15:08:29 2013 @@ -48,7 +48,7 @@ echo Rebaselining feature from trunk cd ../../branches/Program_rc1 svn up -svn merge ^/trunk/Program . +svn merge --reintegrate ^/trunk/Program . echo We have a tree conflict!!! #svn commit -m Rebaselining feature from trunk @@ -127,7 +127,7 @@ echo Perform additional downstream merging cd ../../usr/andy/Program_rc1_main_line svn up -svn merge ^/branches/int/Program_rc1 . +svn merge --reintegrate ^/branches/int/Program_rc1 . echo We have a tree conflict!!! svn status #svn commit -m Rebaselining usr/andy main line from integration main line Remember to use --reintegrate whenever you switch merge direction. The first time your script uses --reintegrate direction switches from trunk-branch to branch-trunk. The tree conflict happens when you switch direction again (to trunk-branch) but don't use --reintegrate. Having to keep track of which direction the prior merge was using is rather cumbersome, which is another reason why this feature is not widely advertised in existing documentation (besides the fact that is was discovered after 1.7 was released). Subversion 1.8 will fix this issue in a much nicer way. I've tried running your script with Subversion 1.8-to-be (i.e. trunk). There is no tree conflict at all, even without the above modifications, because Subversion 1.8 detects the changes of direction automatically.
Re: Merge, reintegrate, and merge with tree conflicts
Okay - I read through and understand the use of reintegrate - but that is what we are using and the script provided in the original post uses. The issue is that even with its use, I'm getting a tree conflict. Please read and test the script from the original post. On Feb 24, 2013, at 7:59 AM, Stefan Sperling s...@elego.de wrote: On Sun, Feb 24, 2013 at 07:55:41AM -0500, James Hanley wrote: Is this a use case that was taken into consideration, and will it be fixed or the functionality/logic added to allow this use case? See my other reply for more details, but yes, this is being addressed: http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
Re: Merge, reintegrate, and merge with tree conflicts
Okay - I read through and understand the use of reintegrate - but that is what we are using and the script provided in the original post uses. The issue is that even with its use, I'm getting a tree conflict. Please read and test the script from the original post. Meant to reply all (twice) On Feb 24, 2013, at 7:59 AM, Stefan Sperling s...@elego.de wrote: On Sun, Feb 24, 2013 at 07:55:41AM -0500, James Hanley wrote: Is this a use case that was taken into consideration, and will it be fixed or the functionality/logic added to allow this use case? See my other reply for more details, but yes, this is being addressed: http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
Re: Merge, reintegrate, and merge with tree conflicts
So what is the proper way to continuously perform the workflow we're trying to do - that is pull changes from origin path into branch, push changes to origin branch from branch, and repeat. Using bidirectional merge (without reintegrate) seems create severe merge conflicts. On Feb 22, 2013, at 7:22 PM, Matthew Pounsett m...@conundrum.com wrote: On 2013/02/22, at 14:15, James Hanley wrote: We are seeing merge tree conflicts where I believe svn is not working as expected. I'm not entirely sure if this is due to a lack of understanding for proper use on our part, but it was my understanding that reintegrate was to be used when pulling changes from a branch and pushing them into the copied from branch. I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way: cd branches svn cp ^/trunk ./mybranch cd mybranch mkdir foo svn add foo svn commit -m added foo to mybranch cd ../../trunk svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch svn merge ^/trunk As soon as the --reintegrate is done, ^/branches/mybranch is dead. [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox/%3C01A9EBD6-CE2D-4565-833D-2252CE2E5B71%40conundrum.com%3E [2] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox/%3C20130207150922.GC28403%40ted.stsp.name%3E
Re: Merge, reintegrate, and merge with tree conflicts
On 2013/02/22, at 14:15, James Hanley wrote: We are seeing merge tree conflicts where I believe svn is not working as expected. I'm not entirely sure if this is due to a lack of understanding for proper use on our part, but it was my understanding that reintegrate was to be used when pulling changes from a branch and pushing them into the copied from branch. I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way: cd branches svn cp ^/trunk ./mybranch cd mybranch mkdir foo svn add foo svn commit -m added foo to mybranch cd ../../trunk svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch svn merge ^/trunk As soon as the --reintegrate is done, ^/branches/mybranch is dead. [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox/%3C01A9EBD6-CE2D-4565-833D-2252CE2E5B71%40conundrum.com%3E [2] http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox/%3C20130207150922.GC28403%40ted.stsp.name%3E
