Let's assume the following scenario:

1. A subcontractor is hired by some company, and receives a Tuleap account based on a LDAP entry.
2. When he/she stops working for that company, his/her Tuleap account is suspended and renamed from xxx to xxx_del.
3. Some time later, that same contractor has to work again for the same company, and for some unknown reason, instead of his/her account being reactivated and renamed back from xxx_del to xxx, the subcontractor receives a new Tuleap account of the same name xxx, based on a modified or new LDAP entry (depending on which attributes are required to be unique in the LDAP schema).

We now have two LDAP entries and two Tuleap accounts (one suspended and one active) for the same person:

mysql> select user.user_id, ldap_uid, user_name, status from plugin_ldap_user join user using(user_id) where ldap_uid like "%con%";
+---------+-------------+-----------------+--------+
| user_id | ldap_uid    | user_name       | status |
+---------+-------------+-----------------+--------+
|     116 | scontractor | scontractor_del | S      |
|     117 | scontractor | scontractor     | A      |
+---------+-------------+-----------------+--------+
2 rows in set (0.00 sec)

From then on, the person can't checkout anymore in SVN. But if we delete the database entry (in plugin_ldap_user) corresponding to the suspended account (delete from plugin_ldap_user where user_id=116; here), the checkout works again perfectly.