I want to be able to
export change requests from the command line.
At least for StarTeam 2009 and earlier, the Command-Line tool (stcmd)
is designed for automating your build process
by allowing you to checkout a set of files in order to build them.
(it also supports checking-in files, but the tool is mostly for checking-out files).
To extract the content of CRs, you can either use a Report (via the UI),
or you can write something in Java that will utilize the StarTeam SDK for that.
The answer posted indicated that a command line option for this is not available. That statement was accurate through StarTeam 11.0, but is no longer the case. The latest version of StarTeam now has a new command line client which will allow you to use SQL-like queries, so you can now SELECT, INSERT, and UPDATE items directly. This means an export is now natively supported by StarTeam. This also gives you a new option to be able to import new items using INSERT; however, your biggest challenges are data field mapping (do you have the right status, severity, etc. and are the field names mapped correctly), and workflow support (does the current state of the data comply with the workflow rules you have defined, assuming you are using a custom APE to support CR workflows).
It is also worth noting that the Report option listed above is not the best option for this via the UI, as there is an Advanced --> Export option that allows you to export all of the selected/filtered items in the top pane into a CSV file. My guess is that this approach would be a better alternative to the Report option, which has limited formatting options and produces output that would be very difficult to use in anything but a printed form.
Related
We are using jBASE 5.6 multivalue database. Is there a way to disable the fact that AccuTerm's WED Editor has the ability to compile programs in the underlying MultiValue database? We are running into an issue where the user is accidentally compiling records instead of programs, which creates corrupt records in the datafiles.
I believe there is also a shortcut key (Function Key) that is in use. Help!
As of AccuTerm Release 7.3a there is no explicit option to disable the compile shortcut in the AccuTerm wED (Windows Editor). There are two techniques you can apply, however, that will work:
Change the Compile command to a single space
Open the wED
Click on the Tools menu at the top
Click on Settings
Click on the Tools tab
In the Compile section, change the text in the Command input from BASIC to a single space. Note that some flavors of PICK use BASIC as the compilation command whereas others use COMPILE. Since you are running jBASE, BASIC applies in this instance but for others such as D3 the command to replace is COMPILE.
It is possible to write a wrapper program to handle compilation for you, which when cataloged could be called from this same Command input. That program could be written to decide whether or not the target record exists in a code file or a data file and then compile or skip, respectively. Due to the fact that PICK systems do not have a file type specification, this logic would be somewhat unique to your environment depending on your practices. Common practice is to denote code files as BP files, i.e. FileNameBP or FileName.BP but again it would depend on your implementation.
For the record, a request to have a more formal option for disabling the Compile command has been submitted to the AccuTerm development team for consideration in the next major release.
I am writing a documentation for a project that involves multiple developers. We use Subversion (SVN) to work on our code base.
I wrote the first draft of the documentation document using HelpNDoc, which I like for the nice tree-view and easy of use; the problem is that there is a single file, so I don't know how to use SVN to allow other developers to contribute to the documentation and update it.
Do you know if it's possible? If not, can you advice a nice software, easy to use, with a tree-view of the documentation that can be used with SVN or makes it possible for multiple users to update it? We use Windows.
HelpNDoc projects are binary files based on the SQLite open source database engine. The advantage is that the whole documentation stored in a single file so it can easily be copied, moved, shared, backed-up...
However one drawback is that it has to be checked-in as binary content in any version control system including Subversion: diff and merge are not possible on those files.
One possible solution would be to use external documents in HelpNDoc's library: each user works on her own document (which can be a Word document, and HTML web-page...) and a master HelpNDoc project is created to include those documents at generation time. See "Include a file at generation time" in the following step by step guide: How to add an item to the library
Amount of files doesn't matter, real format (text/* or binary) - does. If SVN|any VCS can merge two HelpNDoc files with diverged history (just try it by hand), you'll be happy
I once used Helpinator for software documentation, it's pretty close to HelpnDoc but it's storage format is more suitable for version control.
We are in the process of trying to automate our build/deploy processes with the Release Management tool for Visual Studio (formerly InCycle).
The Release Management tool includes a facility to modify settings in a web.config (or app.config). However, there are situations where I'd like to be able to do more than this.
For example, we have URL rewriter rules to automatically redirect HTTP requests to HTTPS. But this won't work (at present) on our dev workstations. So, the "base" version of the web.config doesn't include the rewriter rules -- they are inserted at build/publish time via a web.config transform.
But the Release Management "configuration variable" mechanism won't let me specify more than a single line as a replacement value.
I realize I can remove line breaks, and condense an XML fragment to a single line of text. But I'd rather not have a web.config with lines that are several thousand characters long. And I suspect our IT folks -- who after all may also need to view/edit the file -- would feel rather more strongly about this than I do ;)
In general, the web.config transform mechanism had several modes: you could change a setting but also insert or replace (or delete) an entire section / XML element. While it's nice to no longer be restricted to web.config files (out of the box), the new functionality seems to be much more limited.
Am I missing something? Has anyone else found this to be an issue? What did you do to work around it?
You can still use xml transform to achieve what you want. Make sure that your transform are applied during your build, and the resulting web.config file available in your build output folder will be containing your URL rewriter rules. RM will pick it up from there and apply any other normal token replacement.
Here is a post that help in this regards: http://incyclesoftware.zendesk.com/entries/21487316-InRelease-with-Web-Deploy
If you have multiple stages in your release path, and for example the first stage should not have your URL rewriter section, than it may be a bit harder. You will need to apply your transform as part of your deployment. Multiple components/actions will need to be used for that (xcopy component, xml transform action/component).
I can't find it now, but I know there is some command line tool you can invoke to achieve your xml transformation as part of your deployment.
Apologies for my lack of knowledge about rewriter rules but can they exist in the base version of web.config and be set up so that they don't effectively do anything and 'rewrite' to HTTP?
If that's possible then the way I would do this is to configure a web.config.release file that will create a tokenised web.config via the transformation process. However, rather than use Web One Click Publish I use the /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false arguments in the TFS build definition to apply the transformation. This then results in a build in the drops folder that is completely unaware about any environment it will be deployed to. You then simply use an XCopy Deployer-based component in RM to deploy the website and replace all the tokenised values for that environment. See my blog post here for more details of the technique.
With Makefiles I'm used to being able to write things like:
includedir=$(shell pg_config --includedir)/server
to run an external program, pg_config, with argument(s) --includedir, and include the result in a variable or as part of a variable. So if pg_config --includedir output /usr/include to stdout, the value of includedir would become:
includedir=/usr/include/server
Is there any way to do the equivalent with a Visual Studio project? Run a command, get the result, and substitute it into a property?
I find myself having to edit properties pages all over the place - changing the include directories and library directories for both the x86 and x64 configurations of a project whenever I want to build an extension against a different PostgreSQL version. It is intensely frustrating.
I want to be able to put something like this into Configuration Properties -> C/C++ -> General -> Additional Include Directories:
%(shell pg_config --includedir)
or even better:
%(shell %(PG_CONFIG) --includedir)
where %(PG_CONFIG)'s location is defined in a single place for each platform in the project.
So I'm looking for at least user-defined macros, and preferably the ability to invoke a command line tool and replace the macro with the resulting standard output.
(Preferably in a way that doesn't involve delving into semi-documented UI elements that move and get renamed in every VS version, and that appear and disappear from the various Express editions).
This has been possible in Makefiles for 20 years, there must be a way to do it in VS, right? Or do "Real Windows Developers" generate their VS projects with scripts and build them using MSBuild?
I've looked at some similar questions without finding much of use, e.g.:
Visual Studio - Where to define custom path macros?
In particular, I'm aware of property sheets (View -> Other Windows -> Property Manager), but they don't seem to provide a way to set a value in just one place, they're still per-configuration and per-architecture, so if you have four configurations and two architectures it gets awkward. Unlike with the normal project property editor you can't even apply a change across a group of architectures/configurations, either.
I could use a VS extension, but they require installation into the user's VS, can be version-specific, and seem like a very big hammer for a small problem.
I find myself having to edit properties pages all over the place
That bugged me to no end as well. Property sheets to the rescue! When setting up a major solution in VS10, for example, I had every project pull in a settings.props that contained the common settings, made in only one place. Then go through all the generated or imported projects and kill any explicit value (even if blank) for everything possible. That way things will inherit from property sheets. Select "all configurations" and on each properly use the drop-down to "inherit from...".
I have property sheets for each special library too, just defining the proper #define, include paths, lib paths, etc. Projects that use that particular external lib simply use that property sheet. Users are told, in the worst case, to “edit the XML to change the path to where you have Boost”.
As for setting such a properly to a dynamic determined value, you can do that too. There are property functions you can use.
It sounds like you're going down the same path as I did.
More notes: “prop sheets are per configuration/platform”: If you include a prop sheet at the top-level node for the project itself (not the Debug|Win32, etc. child nodes) it will include it into all current configurations at once. If you edit the properly page, you can choose Multiple or All configurations on the Property dialog box, just as with the usual project use of the Property dialog.
“Custom user macros are well hidden” A property page shows up for that when in a property sheet you created, but not when opening property dialog on a proj file as in the normal File View. The macro will be set in one place (the prop page) and usable as a $(name) in all projects that include it, and even in other property pages that come later in the evaluation sequence.
Let me know how it goes. You should be able to do everything you asked.
—John
In addition to #jdlugosz's answer:
It looks like the traditional way to do this with Visual Studio, before the advent of property functions, was to write a new MSBuild Task. The task can potentially do things like modify a property sheet.
MSBuild supports "inline tasks" where the task code is in the MSBuild project file, rather than a separate assembly, so it might not be neccessary to create a new subproject just for the task.
There are a bunch of built-in tasks, like Exec and CreateProperty that may be useful.
The docs say that:
[The Exec task] is useful when a specific MSBuild task for the job that you want to perform is not available. However, the Exec task, unlike a more specific task, cannot gather output from the tool or command that it runs.
... but that seems to be outdated/wrong so you don't need horrible workarounds.
So, prior to .NET 4.5 I'd probably have to write a custom task for this simple job, because there's no way to feed the command stdout/stderr into the CreateProperty task or have Exec create a property directly. But in 4.5 it looks like I can do it directly. At least in VS Express support for tasks etc is very limited so you'll probably land up editing the XML.
InnoSetup setup executables have command line options to permit unattended or batch file operation - i.e. it is possible to have command-line parameters like /SILENT, /VERYSILENT, such that no "wizard" pages are displayed.
If I add my own wizard pages using CreateInputOptionPage will these still display, i.e. do I need to add further command-line options to suppress these (and provide default responses) as well?
(Yes, I could try it myself, but the answer will likely be useful to others, and there might be further issues I haven't thought of)
When you run with /SILENT or /VERYSILENT dialogs that you create such as CreateInputOptionPage will not be shown. InitializeWizard() is still called and the forms are still created.
So any values you read from these Wizard Pages will be the default values.
You can have specific behavior in Pascal Script when silent by using the WizardSilent() function.
You can also check the parameters sent to the install in Pascal Script using the
ParamCount and ParamStr functions or you can get the whole string using GetCmdTail.