Top 23 Xml Dom Interview Questions You Must Prepare 24.Mar.2023

You can do this using the command-line pin parameter and the wildcard character for the file name.

For example: SS PIN $/MyProject/*.* -VLver1

Here's how to get a list of everything that has changed since a particular date and time from the command line. In the command "a" or "p", refers to a.m. or p.m. respectively. And the ~ is used to indicate you want the history between the dates and times specified. Note that the later date and time must be specified first. -R makes it recursive. SS HISTORY $/mybranch -R -VD3/03/95;3:00p~3/03/95;9:00a

VSS 6.0 fully supports label comments. Label comments, however, are not available in VSS 5.0.

  • Microsoft discourages the use of the SSSCC API. Instead they propose you use the OLE Automation interface. 
  • However, if you still wish to use the API you can request the MSSCCI spec by writing to They will send you the NDA you need to sign to get the spec, and then send you the spec.

These events are not supported as of this posting by Rich Knox of Microsoft: Trapping Rollbacks/Deletions.

This one is not intuitive. From within VSS Explorer, select the project, show history, check Labels Only, find the label of interest, click on Details, select the label text and delete it. Click Close, which will ask if you are sure you want to change the label. Click Yes and you're done.

You can set the SSDIR environment variable to point to the location of the database's SRCSAFE.INI file. • Chuck Kollars discusses the tradeoffs of a single vs multiple databases at his website.

VSS 6.0 supports some administrative functions.

CVS saves its version-control information in RCS files stored in a directory hierarchy, called the Repository, which is separate from the user's working directory.Files in the Repository are stored in a format dictated by the RCS commands CVS uses to do much of its real work. RCS files are standard byte-stream files with an internal format described by keywords stored in the files themselves.To begin work, you execute a "checkout" command, handing it a module name or directory path (relative to the $CVSROOT variable)you want to work on. CVS copies the latest revision of each file in the specified module or directory out of the Repository and into a directory tree created in your current directory.

You may specify a particular branch to work on by symbolic name if you don't want to work on the default (main or trunk) branch.You may then modify files in the new directory tree, build them into output files and test the results.When you want to make your changes available to other developers, you "commit" them back into the Repository.Other developers can check out the same files at the same time.To merge the committed work of others into your working files you use the "update" command. When your merged files build and test correctly, you may commit the merged result. This method is referred to as "copy-modify-merge", which does not require locks on the source files.At any time, usually at some milestone, you can "tag" the committed files, producing a symbolic name that can be handed to a future "checkout" command. A special form of "tag" produces a branch in development, as usually happens at "release" time. When you no longer plan to modify or refer to your local copy of the files, they can be removed.

You must first pin the file at the older version (Show History, select the version of interest and click “Pin”.) Then apply the label to the parent project. The label will be applied to the “tip” revision of the unpinned files, but to the older version of pinned files. Then Unpin the file. The label ‘sticks' even after the pin is removed.

SCCS is much closer to RCS than to CVS, so some of the previous entry applies.

This requires that you iterate through each version of the file looking for the label you want. Once the correct version of the file is identified you can retrieve the comment for that version. Below is some sample VB code demonstrating this: For Each ob VSS Version In ob VSS  Object.Versions If objVSSVersion.Action = "Beta 1" Then MsgBox(objVSSVersion.LabelComment) End If Next

In general, a branch is any mechanism that allows one or more developers to modify a file without affecting anyone other than those working on the same branch.

There are four kinds of "branch" CVS can manage:

@The Vendor Branch. A single vendor branch is supported. The "import" command takes a sequence of releases from a source code vendor (called a "vendor" even if no money is involved), placing them on a special "Vendor" branch. The Vendor branch is considered part of the "Main line" of development, though it must be merged into locally modified files on the RCS Main branch before the "import" is complete. See Section 3H ("import").

@Your Working directory. A checked-out working directory, can be treated like a private branch. No one but you can touch your files. You have complete control over when you include work committed by others. However, you can't commit or tag intermediate versions of your work.

@A Development branch. A group of developers can share changes among the group, without affecting the Main line of development, by creating a branch. Only those who have checked-out the branch see the changes committed to that branch. This kind of branch is usually temporary, collapsing (i.e. merge and forget) into the Main line when the project requiring the branch is completed. You can also create a private branch of this type, allowing an individual to commit (and tag) intermediate revisions without changing the Main line. It should be managed exactly like a Development Branch -- collapsed into the Main line (or its parent branch, if that is not the Main Branch) and forgotten when the work is done.

@A Release branch. At release time, a branch should be created marking what was released. Later, small changes (sometimes called "patches") can be made to the release without including everything else on the Main line of development. You avoid forcing the customer to accept new, possibly untested, features added since the release. This is also the way to correct bugs found during testing in an environment where other developers have continued to commit to the Main line while you are testing and packaging the release. Although the internal format of this type of branch (branch tag and RCS branches) is the same as in a development branch, its purpose and the way it is managed are different. The major difference is that a Release branch is normally Permanent. Once you let a release out the door to customers, or to the next stage of whatever process you are using, you should retain forever the branch marking that release.

Since the branch is permanent, you cannot incorporate the branch fixes into the Main line by "collapsing" (merging and forgetting) the release branch. For large changes to many files on the release branch, you will have to perform a branch merge using "update -j -j ". (See 4C.7) The most common way to merge small changes back into Main line development is to make the change in both places simultaneously. This is faster than trying to perform a selective merge.

CVS is used to keep track of collections of files in a shared directory called "The Repository". Each collection of files can be given a "module" name, which is used to "checkout" that collection. After checkout, files can be modified (using your favorite editor), "committed" back into the Repository and compared against earlier revisions. Collections of files can be "tagged" with a symbolic name for later retrieval. You can add new files, remove files you no longer want, ask for information about sets of files in three different ways, produce patch "diffs" from a base revision and merge the committed changes of other developers into your working files.

CVS uses RCS to do much of its work and absolutely all the work of changing the underlying RCS files in the Repository. RCS comprises a set of programs designed to keep track of changes to individual files. Of course, it also allows you to refer to multiple files on the command line, but they are handled by iterating over individual files. There is no pretense of coordinated interaction among groups of files. CVS's main intent is to provide a set of grouping functions that allow you to treat a collection of RCS files as a single object. Of course, CVS also has to do a lot of iteration, but it tries its best to hide that it is doing so. In addition, CVS has some truly group-oriented facets, such as the modules file and the CVS administrative files that refer to a whole directory or module. One group aspect that can be a bit confusing is that a CVS branch is not the same as an RCS branch. To support a CVS branch, CVS uses "tags" (what RCS calls "symbols") and some local state, in addition to RCS branches. Other features offered by CVS that are not supported directly by RCS are @Automatic determination of the state of a file, (e.g. modified, up-to-date with the Repository, already tagged with the same string, etc.) which helps in limiting the amount of displayed text you have to wade through to figure out what changed and what to do next. @A copy-modify-merge scheme that avoids locking the files and allows simultaneous development on a single file. @Serialization of commits. CVS requires you to merge all changes committed (via "update") since you checked out your working copy of the file. Although it is still possible to commit a file filled with old data, it is less likely than when using raw RCS.

DOM is a platform independent, World Wide Web Consortium (W3C) standard form of representation of structured documents as an object-oriented model. It is an application programming interface so as to access HTML and XML documents.

Document Object Model (DOM) is used to query, traverse and manipulate documents like XML or HTML documents. DOM is best suited where the document must be accessed repeatedly or out of sequence order. DOM allows accessing the contents of a web page. It also allows dealing with events that allows capturing and responding to user's actions. There are different levels of DOM standards depending on the compatibility of the browsers.

DOM is Document Object Model. It is used to read data from a XML document. It is more commonly used in applications where data in the document needs to be repeated accessed. DOM supports navigation in any direction. XML DOM is typically used for XML documents. The DOM defines the objects and properties of all document elements, and the methods (interface) to access them.

The XMLHttpRequest object is used to connect to the server through http. Scripts use it to do so programmatically.

The EventTarget interface needs to be implemented if an object implements the XMLHttpRequest interface. Also, an XMLHttpRequest() constructor needs to be provided by objects that implement the Window interface.

"CVS" is an acronym for the "Concurrent Versions System". CVS is a "Source Control" or "Revision Control" tool designed to keep track of source changes made by groups of developers working on the same files, allowing them to stay in sync with each other as each individual chooses.

  • SAX parser works incrementally and generates events that are passed to the application. DOM parser reads the whole XML document and returns a DOM tree representation of xml document
  • In DOM the xml file is arranged as a tree and backward and forward search is possible In SAX traversing in any direction is not possible as Top to bottom approach is used.
  • SAX is essentially an API for reading XML, and not writing it. DOM allows you to read and write.

The HTML DOM API specializes and adds the functionality to relate to HTML documents and elements. It addresses the issues of backwards compatibility with the Level 0 of DOM and provides mechanisms for common and frequent operations on HTML documents.

Need to use the '-v' switch with an 'L' after it to indicate a label (-R is for recursive): SS GET $project -VLmy  label -R