Category: Subversion

Posted on

Delete the merge info, when problems with integration

Real World Fix (See below for original email with details)

Three steps to accomplish the task, the first one shows you are in the right place, the second actually deletes all merge info and the final step reverts back the merge info for the root folder:

Use this to see if there is a problem:

svn propget -R svn:mergeinfo .

And then the following to fix it:

[~/tmp/trunk]$  svn status
[~/tmp/trunk]$  svn propdel svn:mergeinfo -R .
[~/tmp/trunk]$  svn revert .

Example:

svn pd svn:mergeinfo halwebsite/js/jquery/date.js

From subversion Wiki:

Reintegration Problem

At certain times, you get the following error, even though you have merged trunk changes to branch:

svn: Cannot reintegrate from 'https://some.server/branches/branch' yet:
Some revisions have been merged under it that have not been merged into the reintegration target; merge them first, then retry.

Older versions of subversion seem to cause mergeinfo problems with mergeinfo properties for individual files. This problem can be detected by recursively listing properties in the branch:

svn pl -R $SVN/branches/branch/|egrep -B 4 svn:mergeinfo

If individual files and subdirectories have mergeinfos, you can delete them:

svn pd -R svn:mergeinfo branch/subdirectory_with_mergeinfo/

and commit the changes.

-----Original Message-----
From: Guillaume Radde [mailto:guillaume.radde@redhat.com]
Sent: Tuesday, July 10, 2012 9:26 AM
To: Ruckman, Maurice (HAL)
Cc: Fillman, Eric (HAL); Thompson, Sonya (HAL)
Subject: Deleting mergeinfo

To delete svn:mergeinfo from all files and folder except the parent folder:

-----------------------------------------------------------------
[jboss1@haldevjbs05 ~/tmp/trunk]$  svn status
[jboss1@haldevjbs05 ~/tmp/trunk]$  svn propdel svn:mergeinfo -R .
property 'svn:mergeinfo' deleted from '.'.
property 'svn:mergeinfo' deleted from 'hal-ejb/src/main/java/com/sbn/shx/util/SbnShxIconUtil.java'.
svn: Attempting to delete nonexistent property 'svn:mergeinfo'
[jboss1@haldevjbs05 ~/tmp/trunk]$  svn revert .
Reverted '.'
[jboss1@haldevjbs05 ~/tmp/trunk]$  svn status
M      hal-ejb/src/main/java/com/sbn/shx/util/SbnShxIconUtil.java
[jboss1@haldevjbs05 ~/tmp/trunk]$
-----------------------------------------------------------------

-------------------------------------
Guillaume Radde
Senior Consultant, Red Hat Consulting
guillaume.radde@redhat.com
http://www.redhat.com
-------------------------------------

Posted on

Keeping a Reintegrated Branch Alive

There is an alternative to destroying and re-creating a branch after reintegration. To understand why it works you need to understand why the branch is initially unfit for further use after it has been reintegrated.

Let's assume you created your branch in revision A. While working on your branch, you created one or more revisions which made changes to the branch. Before reintegrating your branch into trunk, you made a final merge from trunk to your branch, and committed the result of this merge as revision B.

When reintegrating your branch into the trunk, you create a new revision X which changes the trunk. The changes made to trunk in this revision X are semantically equivalent to the changes you made to your branch between revisions A and B.

If you now try to merge outstanding changes from trunk to your branch, Subversion will consider changes made in revision X as eligible for being merged into the branch. However, since your branch already contains all the changes made in revision X, merging these changes can result in spurious conflicts! These conflicts are often tree conflicts, especially if renames were made on the branch or the trunk while the branch was in development.

So what can be done about this? We need to make sure that Subversion does not try to merge revision X into the branch. This can be done using the --record-only merge option, which was introduced in the section called "Blocking Changes".

To carry out the record-only merge, get a working copy of the branch which was just reintegrated in revision X, and merge just revision X from trunk into your branch, making sure to use the --record-only option.

This merge uses the cherry-picking merge syntax, which was introduced in the section called "Cherrypicking". Continuing with the running example from the section called "Reintegrating a Branch", where revision X was revision 391:

$ cd my-calc-branch
$ svn update
$ svn merge --record-only -c 391 ^/calc/trunk
$ svn commit -m "Block revision 391 from being merged into my-calc-branch."

Now your branch is ready to soak up changes from the trunk again. After another sync of your branch to the trunk, you can even reintegrate the branch a second time. If necessary, you can do another record-only merge to keep the branch alive. Rinse and repeat. It should now also be apparent why deleting the branch and re-creating it has the same effect as doing the above record-only  merge. Because revision X is part of the natural history of the newly created branch, Subversion will never attempt to merge revision X into the branch, avoiding spurious conflicts.

Posted on

Merge into RC (Release Candidate)

scan/replace the following two items:
webss-9999-new-feature
WEBSS-XXX

Checkout new copy of feature to your VM
svn co http://halsvn01/svn/hal/branches/features/webss-9999-new-feature

Merge feature with trunk
svn merge http://halsvn01/svn/hal/trunk

Commit Merge
svn commit -m "Sync feature branch webss-9999-new-feature with trunk. Fix WEBSS-XXX"

Checkout new copy of trunk
svn co http://halsvn01/svn/hal/trunk

Merge Code via Command Line
svn merge --reintegrate http://halsvn01/svn/hal/branches/features/webss-9999-new-feature
svn commit -m "Reintegrate feature branch webss-9999-new-feature into trunk. Fix WEBSS-XXX"

Delete Feature Branch After Successful Merge (why so quick to delete?)
svn delete http://halsvn01/svn/hal/branches/features/webss-9999-new-feature -m "Feature merged to trunk, deleting for cleanup"

Problems Encountered?

If there is a problem with merge-info where Subversion is saying there are "Missing range errors", then you should check to see if there is merge info on files or folders other than just the parent folder.  See here.

You can resolve conflicts with the switch --accept=working, which takes the working copies version of things.  When we originally started using SVN, the meta data became out of sync due to folks checking in individual files inside Eclipse, instead of checking in their entire feature branch.  Here's an example of usage:

svn resolve --accept=working halwebsite/com

Merge Code via Eclipse

  • In the IDE, go to File >> Import >> Maven >> Import Existing Maven Project & import the RC project
  • Right click the hal-parent (the dir might be named after the RC, so 12.17-RC) and say merge
  • Select the reintegrate radio option
  • Review the changes
  • If okay, commit the changes from command line
Posted on

Adding subversion to LDAP

-----Original Message-----
From: Guillaume Radde [mailto:guillaume.radde@redhat.com]
Sent: Friday, April 27, 2012 12:13 PM
To: Tripp, Donald (HAL)
Cc: Hofsetz, Therron (HAL); Thompson, Sonya (HAL); Fillman, Eric (HAL); Doan, Thomas (HAL Contractor); Phatak, Sheetal (HAL); Bojja, Sridhar (HAL Contractor); Augustine, Anila (HAL); Ruckman, Maurice (HAL); HAL DistList: IS UNIX
Subject: Re: Noticen of Intent: Restart halsvn01

Thanks for taking care of that Don. Also, on the long term it might be a good idea to have the subversion server use LDAP for authentication so that new accounts get automatically created.

The subversion server relies on Apache for authentication (developers access subversion through http:// protocol). So the steps to do so would be the following:

1) Edit the file /etc/httpd/conf.d/svn.conf and replace "AuthUserFile /etc/httpd/conf/.htaccess" with equivalent LDAP authentication section

2) In the /etc/httpd/conf/svn_acl, replace the name of user with their equivalent LDAP login

That should be it...

Guillaume

Posted on

Merging from a revision

Example that wants just what was done in revision 2723 in trunk:

svn merge -c [good_revision] [repository_url]
svn merge -c 2723 http://halsvn01/svn/hal/trunk

This will rollback revision 2723 in trunk, pay attention to the negative sign in front of the revision number:

svn merge -c -[bad_revision] [repository_url]
svn merge -c -2723 http://halsvn01/svn/hal/trunk

Older methods as show by Guillaume below, the one above are now supported and recommended by me.

svn merge ~/branches/features/your-feature-t0-merge-no-ending-slash -r 995:999

Where 995 represent the first revision and 999 represents the last revision to merge

$ svn merge -c 614 https://secreturl/trunk or $ svn merge -r 613:614 https://secreturl/trunk.

The first means apply changes in revision 614 only, while the second form means take all changes required to go from r613 to r614 and apply them here.

Posted on

Subversion Maintenance – Adding Users

1. SSH to the subversion server
Putty to halsvn01.hq.halw.com

sudo to root:
The Unix team added sudoers file for mlr, ezf, and sst to be able to do the following, additional users would needed added by Unix team:

sudo /usr/bin/htpasswd -m /etc/httpd/conf/.htaccess
sudo /bin/vi /etc/httpd/conf/svn_acl
sudo /usr/bin/vim /etc/httpd/conf/svn_acl

originally Guillaume used:
sudo su -

2. Edit the configuration files

The following will allow you to enter the user's password:

cd /etc/httpd/conf
ls -la
htpasswd -m /etc/httpd/conf/.htaccess user-account

The following will allow defines access control in subversion:
vim svn_acl

vim command
[Esc] [:] [q] to quit without saving
[Esc] [:] "wq" to write (save) and quit

[i] - Insert

You will change users in groups which propagate down through the rest of the script, here's the start of the script:

[groups]

## For HAL
#developers
dev = aja, szb, ezf, sst, mlr, sxp, kxs, wgh, mad, mwm, c-rgong, c-rsmith, jeff, c-rradhakrishnan, jay, guillaume, c-mhartman, c-fcastro, c-dgreca, @rm, @rev, @qa