This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 158272 - Probs w/ NetBeans-Subversion-RDoc-Kenai stack
Summary: Probs w/ NetBeans-Subversion-RDoc-Kenai stack
Status: NEW
Alias: None
Product: ruby
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@ruby
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-10 10:53 UTC by ericarmstrong
Modified: 2011-01-28 20:13 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ericarmstrong 2009-02-10 10:53:01 UTC
NetBeans, Subversion, RDoc, and Kenai do not seem to play well together.

Troubles started when I added generated RDocs from my Ruby project to the source hierarchy.
(Big mistake. The files aren't rendered in Kenai source view, so it was pointless to upload them.)

Problem #1
----------
When regenerated, NB sees the doc/ directory as "new", and attempts an SVN commit on that basis.
But since the docs/ dir already exists in the repo, Kenai SVN module rejects the commit.

Problem #2
---------- 
Although the doc/ dir is rejected as "already exists", it's not actually shown in the NB commit-list,
so you can't modify the setting. 

Problem #3 (maybe)
----------
For things that do exist, like doc/classes, clicking on the entry in the commit list provides
only one additional option (ignore). (I wanted to change the entry to "locally modified", but
I can see where the SVN client would have a problem with that.)

Problem #4
----------
To put an end to my troubles, I decided to remove the rdoc files from SVN control. (Seemed like
a reasonable thing to do.) Funny thing is, I couldn't to find a way to do that, since none of the
NB SVN menus have a "delete" option on them. (One exists in Tortoise SVN, so I expected a similar
entry in NB.)

I found a previously filed bug that says NB SVN deletes files that don't exist, so I deleted
the doc/ directory. Everything under it was removed, but the directory itself remained, which
meant that SVN didn't generate a "delete doc/" instruction (or anything under it).

I tried removing the directory from the file explorer, but then the SVN commit failed, saying that
the client version was out of date.

So I updated the client repo (which restored the docs), and tried the delete again. I thought I 
was in a trap with no exit, but the delete actually worked this time, and thye expected SVN delete-command
was generated for the commit.

(So at this point, I've worked around the issues. But I think it's fair to say that things are not
playing together as nicely as they should.)
Comment 1 Tomas Stupka 2010-09-28 14:23:18 UTC
> Problem #1
> ----------
> When regenerated, NB sees the doc/ directory as "new", and attempts an SVN commit on that basis.
not very familiar with ruby but if the regeneration created locally new files than they are new even if there is already something on the server. The only other reason why the files where regarded as new is that the whole doc folder was removed first (including the .svn metadata fodlers) what of course would mess up the the working copy. 
A following svn update might have helped but might also have caused conflicts (depends on the new file contents)
as this seems to be the root of your problem - will reassign to ruby project for further evaluation


> since none of the NB SVN menus have a "delete" option on them
just use the delete command in a files context menu, the appropriate svn command will be called by the IDE

> Everything under it was removed, but the directory itself remained
directories deleted by the svn delete command, and what actually s the correct and expected way how to remove files in a svn wc, remain on the disk until the next commit. After a commit will be definitelly removed from your disk.