Bug 707428 - Handling of svn outputs prevent login when using different username.
Summary: Handling of svn outputs prevent login when using different username.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Topic Tool
Classification: Other
Component: cli-Topic_Tool
Version: 0.0.x
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Stephen Gordon
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-25 02:07 UTC by Stephen Gordon
Modified: 2012-01-20 21:05 UTC (History)
1 user (show)

Fixed In Version: topic-tool-0.0.9-0.fc16.noarch.rpm
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-20 21:05:53 UTC


Attachments (Terms of Use)

Description Stephen Gordon 2011-05-25 02:07:42 UTC
Description of problem:

Where the user has not previously imported a topic or used the svn repository and their username is different to that they use for svn topic tool prevents login.

[shadowman@f14 ~]$ topic import Topic_Based_Authoring.xml Concepts/
Is this topic intended for use more than once within a single document or set? If not then choose (L)ink Targetable topic. Otherwise choose (R)eusable topic. Access (H)elp for further information. (L/R/H): 
L
INFO: Attempting topic import, 0 images are also being imported.
Password for 'shadowman': 

ki^CERROR: Authentication realm: <https://svn.devel.redhat.com:443> Red Hat only: Kerberos Login
ERROR: Authentication realm: <https://svn.devel.redhat.com:443> Red Hat only: Kerberos Login
ERROR: Username: svn: Caught signal
ERROR: Unable to import topic.
You have new mail in /var/spool/mail/root

STDERR needs to be provided on demand not once the process completes.

Comment 1 Stephen Gordon 2011-07-06 22:09:39 UTC
This is also a problem when attempting to use the new publican build process via topic tool (`topic publican Installation_Guide package --cvs --lang=en-US` or `topic brew Installation_Guide` if using the version in trunk.

The problem results because of the way we are calling these executables, in particular without attaching a terminal/stdin to them.

Workaround for cvs builds is to topic export and then use publican as normal to package from the exported directory. Workaround for SVN authentication is to have kinit'd previously.

Comment 2 Stephen Gordon 2011-07-06 22:25:34 UTC
(Probably wasn't clear from the previous comment but, yes, I intend to fix this asap).

Comment 3 Stephen Gordon 2011-07-09 02:48:41 UTC
I think as well as handling the process call properly I am going to:

- remove the `topic brew` usage (replace with a warning to tell the user what to do instead).
- remove the `topic publican` usage (replace with a warning to tell the user what to do instead).

To replace these actions I would like to either:

- extend `topic export` such that any further arguments are treated as a command to run in the newly exported book, for example:

   topic export Installation_Guide publican package --cvs --lang=en-US

or

- add `topic <bookname>` which would function in a similar fashion:

   topic Installation_Guide publican package --cvs --lang=en-US

The downside of either approach is that we could no longer assume that the user wants to have the exported directory removed once the command has run as we do now as we are no longer restricting them to running package operations.

The upside of course is that the topic tool becomes less tired to a specific publican package flag (--cvs, --brew, possibly --git soon). From my point of view this also brings the usage closer to the standard publican usage as opposed to the current implementation which hides bits and pieces which is confusing. For instance we implicitly set --brew and set the --lang to en-US where a language isn't specified.

Comment 4 Stephen Gordon 2011-07-09 02:52:59 UTC
One alternative I have been thinking about is making the export action actually work from the same level as the publican.cfg which would allow this usage instead:

   topic publican package --cvs --lang=en-US

The book directory name would be determined based on the CWD rather than the command line arguments. This would also remove the confusion users have with the fact that topic tool builds start out at a different level in the directory tree to normal publican builds.

Comment 5 Stephen Gordon 2011-07-09 04:49:49 UTC
Looking further into this I have managed to make the topic export work as described in c#4. Looking at the work I had previously done I had already made a publican topic verb that executes the export and then runs publican commands within it. The shortcut usage for this allows, for example:

   topic package --cvs --lang=en-US

The way the topic tool in my working copy now responds to this is to:

1) Clean any previous export directory, ../${CWD_NAME}_Export/
2) Export the book and all topics to an export directory, ../${CWD_NAME}_Export/
3) Runs the publican <publican_verb> <...> command within the export directory.

As with the updated topic export command the expectation is that this is run from the root of the book, where the publican.cfg exists. Currently the only publican commands for which the shortcut is enabled are build and package but it is relatively easy to add more. 

Still need to work on ensuring the exec call handles the interactive commands correctly.

Comment 6 Stephen Gordon 2011-11-28 21:24:21 UTC
Allows topic export to be run from above the root of the book (as it always has been) or within the root of the book. The topic brew logic is being dropped as chasing publican each time something changed was not deemed a long term possibility. Instead the workflow for brewing remains:

topic export Book_Name
cd Book_Name_Export
publican package --cvs --lang=en-US

The only difference being of course that the export could now be performed from Book_Name/ instead.

Committed revision 75244.

Comment 7 Stephen Gordon 2012-01-20 21:05:53 UTC
topic-tool-0.0.9-0.fc16.noarch.rpm


Note You need to log in before you can comment on or make changes to this bug.