@@ -894,9 +894,10 @@ def add(args)
894
894
# operations in order.
895
895
#
896
896
# Each of the operations appearing in the Array must itself be an Array
897
- # with exactly three elements: an operator:: must be :add, :replace, or
898
- # :delete an attribute name:: the attribute name (string or symbol) to
899
- # modify a value:: either a string or an array of strings.
897
+ # with exactly three elements:
898
+ # an operator :: must be :add, :replace, or :delete
899
+ # an attribute name :: the attribute name (string or symbol) to modify
900
+ # a value :: either a string or an array of strings.
900
901
#
901
902
# The :add operator will, unsurprisingly, add the specified values to the
902
903
# specified attribute. If the attribute does not already exist, :add will
@@ -939,13 +940,13 @@ def add(args)
939
940
# may not get extended information that will tell you which one failed.
940
941
# #modify has no notion of an atomic transaction. If you specify a chain
941
942
# of modifications in one call to #modify, and one of them fails, the
942
- # preceding ones will usually not be "rolled back, " resulting in a
943
+ # preceding ones will usually not be "rolled back", resulting in a
943
944
# partial update. This is a limitation of the LDAP protocol, not of
944
945
# Net::LDAP.
945
946
#
946
947
# The lack of transactional atomicity in LDAP means that you're usually
947
948
# better off using the convenience methods #add_attribute,
948
- # #replace_attribute, and #delete_attribute, which are are wrappers over
949
+ # #replace_attribute, and #delete_attribute, which are wrappers over
949
950
# #modify. However, certain LDAP servers may provide concurrency
950
951
# semantics, in which the several operations contained in a single #modify
951
952
# call are not interleaved with other modification-requests received
0 commit comments