[Issue 1014] New - Commit dialog does not honour bugtraq:* contract

[Adrian Price]

http://subclipse.tigris.org/issues/show_bug.cgi?id=1014
                 Issue #|1014
                 Summary|Commit dialog does not honour bugtraq:* contract
               Component|subclipse
                 Version|current
                Platform|All
              OS/Version|All
                     URL|
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P2
            Subcomponent|UI
             Assigned to|issues@subclipse
             Reported by|adrianp






------- Additional comments from adrianp@... Tue Oct 20 04:47:07 -0700 2009 -------
The Subclipse [1.6.2] commit dialog does not honour the bug tracker integration
contract as described in the Subclipse help, in that for linked projects it
ignores bugtraq:* properties defined in parent working copy directories.

Consider the following working copy layout on disk:
some-non-wkg-cpy-dir
 + wkg-cpy-root-1 [defines bugtraq:* properties]
  + features
   + feature-1-1
     .project
     etc...
  + plugins
   + plugin-1-1
     .project
     etc...
 + wkg-cpy-root-2 [defines bugtraq:* properties]
  + features
   + feature-2-1
     .project
     etc...
  + plugins
   + plugin-2-1
     .project
     etc...

According to
http://guest:guest@.../svn/tortoisesvn/trunk/doc/issuetracker
s.txt:

"- If the properties are not set for a folder, the client should search upwards
  in the working copy for them until the working copy root is reached.
...
Q: But if I have many folders, I have to add those properties to each one of
   them! Isn't there a better way?
A: Sorry, but no. But if you can be sure that each user checks out only from
   e.g. /trunk/ and not some subfolder, then it's enough if you set the
   properties there. The clients will search for those properties the path up
   to the working copy root for those properties.
"

The above statement implies that the commit dialog for any of the projects
feature-1-1, plugin-1-1, feature-2-1, plugin-2-1 etc. should detect the
bugtraq:* properties inherited from the respective parent working copy root
directories wkg-cpy-root-1, wkg-cpy-root-2 and so on. However, the commit
dialog currently only shows bugtraq fields if the properties are defined on
each and every project directory.

In our own case we have 30-odd such working copy roots, for which maintaining
the bugtraq:* properties is a just-about-manageable task, but in excess of 270
indirect child projects, for which maintaining bugtraq:* properties is most
definitely *not* a viable proposition. FWIW all such working copy roots relate
to the same SVN repository, but developers only ever check out a subset.

BTW, TortoiseSVN does handle such working copy structures correctly.

Thanks,

Adrian Price
Senior Architect, TIBCO Software Inc.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1046&dsMessageId=2409350

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@...].

[Mark Phippard-3]

http://subclipse.tigris.org/issues/show_bug.cgi?id=1014






------- Additional comments from markphip@... Tue Oct 20 05:36:51 -0700 2009 -------
Subclipse crawls your working copy using the Eclipse IResource object.  These Eclipse objects are not able
to look outside your workspace, so they stop at your project roots.

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1046&dsMessageId=2409370

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@...].

[Adrian Price]

http://subclipse.tigris.org/issues/show_bug.cgi?id=1014






------- Additional comments from adrianp@... Tue Oct 20 06:21:38 -0700 2009 -------
Yep, I figured that would be the reason behind the limitation. However, it is
not true to say that IResource objects cannot 'look' outside of the workspace
and in fact I don't believe there is any logical reason why Subclipse could not
honour the general bugtraq contract.

For workspace resources that are stored in the local file system,
IResource.getLocation() : IPath returns the OS file system path of the local
content. It ought to be possible to use the standard java.io.File.getParentFile
() : File API to ascend the local file system tree in order to collect
inherited bugtraq:* properties.

I appreciate that normally the use of Java file I/O in an Eclipse plug-in would
be considered an anti-pattern but in this case there's no alternative.

Thanks for the feedback Mark; in the light of the above do you agree that it
ought theoretically to be possible to resolve this issue?

--A

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1046&dsMessageId=2409377

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@...].