[Issue 166] New - Some CVS/SVN changes might not be visible to users

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[Issue 166] New - Some CVS/SVN changes might not be visible to users

vsizikov
https://hudson.dev.java.net/issues/show_bug.cgi?id=166
                 Issue #|166
                 Summary|Some CVS/SVN changes might not be visible to users
               Component|hudson
                 Version|current
                Platform|All
              OS/Version|All
                     URL|
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|www
             Assigned to|issues@hudson
             Reported by|vsizikov






------- Additional comments from [hidden email] Fri Nov 17 19:01:44 +0000 2006 -------
There are two cases reported:

From Sven:
"I am not quite sure if I got this diagnosed correctly, but I will try
to describe what I assume is happening.

1. Hudson is polling SVN and detects changes.
2. Hudson triggers the build.
3. During SVN co (or update maybe) a network connection error occurs.
4. The build fails, no changelog
5. Manual restart of build (no further changes in the repository so far)
6. Successful build
7. Still no changelog

Seems Hudson gets confused in case the assumed chain of events is broken."

From Vladimir:
"I've seen similar behavior when, for example, I misconfigured SVN
settings (like, providing two URLs for two modules where one of the
modules does not exist due to error in URL), and then Hudson tries to
check out sources, fails for the second module, and no changes written
in the change log - so from the user's point of view some recent
changes in the first module will never be visible."

Kohsuke response:
"Hudson's changelog computation is based on comparing the current files
in the workspace vs the set of files after update.

So Vladimir's case makes sense to me. If the update of the 2nd module
failed, then the 1st module is already updated, so next time a build
runs it misses the update of the 1st module --- that can be fixed by
making sure that changelogs are written per module."

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]