This blog post saved my day. I was able to keep a page look relatively the same by using browser specific css definitions. Maintaining separate css definitions is undesirable, but necessary to work within the current situation.
Archive for March, 2009
Using svn merge
I wanted to merge one revision I made in the trunk into one of the branches. So, I used Subversion’s svn merge command to accomplish this. Thanks to Ray M. for explained the Subversion merge command to me. Here are my notes:
Before I start, I identified the following information:
- The target revision number in trunk that I wanted to merge into the branch. In this case, I assigned a revision number of 100.
- The full URL for the trunk. I found this information by running
svn infoand looked forRepository Root. In my environment, the trunk is simply [Repository Root]/trunk.
With the above information, I was ready to do a dry-run to make sure the command produced the outcome I wanted. Here is what I ran:
cd [local branch directory] svn merge -r99:100 --dry-run [Repository Root]/trunk
I basically changed directory into the branch where I want merge the trunk revision to. Next, I ran the svn command with the merge sub-command. For the revision numbers, I specified the revision I wanted to merge from the trunk as the second number and the first number was simply the second revision minus one. This essentially said to merge changes that happen between revision 99 and 100, which was equivalent to all the changes committed in revision 100. The URL to trunk told the merge sub-command where to look for the specified source revision number.
Once I was happy with the dry-out output, I ran the command again without the --dry-run option. This effectively merge revision 100 from trunk into the branch. Right after that, I ran svn diff to check if the diff output was what I expected before I commit the changes.
cross-domain iframe communication
This post is very helpful for me to send small bits of information across iframes. However, this creates a new challenge with history manager that uses the same mechanism to store page state. Whenever an iframe uses fragment identifiers to send a message across iframes, the page state for the target iframe is wiped out. If the message leads to a new page state, this actually matches the intended use of history manager. However, for scenarios where the message does not lead to a new page state, it may lead to an inconsistent sate between the representation in the URL and what’s displayed on the target iframe. One work around is to reset or synchronize the page state for such use cases, which can generate unnecessary reload/AJAX calls. If you have a cleaner approach, let me know.
