From 08523ac76b1f48bb060883df00abfaf7ecb04f5e Mon Sep 17 00:00:00 2001
From: Eric Kesseler <eric.kesseler@devolo.de>
Date: Mon, 17 Aug 2015 12:20:35 +0200
Subject: [PATCH] Using paragraph for title

---
 .../hudson/scm/SubversionSCM/help-usingCommitTimes.html         | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/main/resources/hudson/scm/SubversionSCM/help-usingCommitTimes.html b/src/main/resources/hudson/scm/SubversionSCM/help-usingCommitTimes.html
index d4acb9de6..3a76034cb 100644
--- a/src/main/resources/hudson/scm/SubversionSCM/help-usingCommitTimes.html
+++ b/src/main/resources/hudson/scm/SubversionSCM/help-usingCommitTimes.html
@@ -1,5 +1,5 @@
 <div>
-  If set Jenkins will set the file timestamps to the last commit time (of each file) when doing a checkout or an update. Otherwise Jenkins will set the current date as the timestamp of each file.
+  <p>If set Jenkins will set the file timestamps to the last commit time (of each file) when doing a checkout or an update. Otherwise Jenkins will set the current date as the timestamp of each file.</p>
   <p>
     Normally the working copy files have timestamps that reflect the last time they were touched by any process. This is generally convenient for most build systems as they look at timestamps as a way of deciding which files need to be recompiled.
     In other situations, however, it's sometimes nice for the working copy files to have timestamps that reflect the last time they were changed in the repository. The svn export command always places these 'last-commit timestamps' on trees that it produces.