I am trying to come up with something similar to the "Revisions" tab for a user story. I have everything I need but the description.
Should I be able to take the revision number or ID and search the "Revision History" residing in the story?
I wasn't sure if the revision contents would be time sensitive.
I found the following example.
Following this in order to gain revision history.
https://github.com/nmusaelian-rally/last-revision-of-recently-updated-artifacts
Related
I have been tasked with the following problem:
Using SQL, query Wikipedia and obtain the number of times the word 'nice' appears. Also, display the name of the article and the number of times per article this word 'nice' shows up.
I am having trouble actually accessing the contents of a Wikipedia page with SQL. I am using Quarry to play with queries, and I simply can't find where the contents of a page are stored. I am using this as a reference: https://www.mediawiki.org/w/index.php?title=Manual:Database_layout/diagram&action=render
I thought that a page's contents might be stored in the page table, or perhaps the content table. None of these fields and their datatypes make sense to me though (as far as saving the actual text contents of a page). Where is the actual content of an article stored? Can anyone provide a brief description of how this database actually represents a Wikipedia page?
A pages text is a little less straightforward. In MediaWiki each page (stored in the page table) can have multiple revisions (stored in the revision table), and each revision has its text in the text table. You will most likely want to do a join over these tables to connect the information.
Unfortunately this is a very general question...
Imagine an authoring application to create e.g. electric schematics. Engineers draw schematics until they are satisfied with their product and it's ready for production.
At this point a "Revision" would be initiated (say Revision "#1") . From now on all data/documents of this revision can't be changed anymore. It's read-only.
As time goes by, the engineers have smart ideas and start to update the existing schematics based on Revision #1. They add new features, remove features, replace some components with newer versions etc. until they have a Revision #2.
A common requirement this then: What has changed between Rev.1 and 2? Some delta reports are needed.
What would/could that mean with RavenDB?
If the engineers start a new revision, would that mean to
copy all documents and insert them with a new Id like
"/proj-1/rev-2/component-1000"? How would I update my relations between documents
then? Adjust all relations "manually"?
Snapshot the DB? Can I compare a snapshot DB with the current DB?
How would I find all the delta between those revisions?
If I do not copy all documents or snapshot them, would I need to book-keep all changes in separate documents (event-log style) i.e. DocX has been deleted, DocY has been updated with Value1, DocZ has been added etc?
I know that RavenDb has its own revision system. It's based on single changes of a document. Could this be used for advantage here?
Any hints how to model such a system would be highly appreciated.
RavenDB has the notion of revisions for documents, which create read only snapshot of the document. They are created whenever you modify the document.
For your needs, I would recommend creating: plans/1238-A as the document itself.
Whenever you need to stamp a read-only revision, use: plans/1238-A/revisions/1 or something like that.
I would recommend not modifying any references, point to the same location, but when reading the revision, ask the referenced revision.
Is it possible to promote a file without specifying an issue number?
Related to that question, I see some files which have histories for which the column "Issues" is blank. How does that happen?
Promoting against and issue is an option, rather than a requirement. An AccuRev depot does not have an AccuWork schema until an administrator creates one. Even then, this does not automatically require promoting to an issue. Within the Accuwork schema, this feature can be enabled using the Change Packages tab.
To your second point "... some files which have histories for which the column "Issues" is blank. How does that happen?"
If you've changed over from non-Issue based development to Issue based development and have not associated the files, those with active or (member) status, with Issues, that column will be blank.
More likely some one promoted foo.c to Issue 15. Then opened up Issue 15 and removed foo.c from the Issue. In this case the column will be blank too.
The solution is to find these files, look for the "Unaffiliated Changes", select them, and choose "Send To Issue" then provide the correct Issue number.
We have a CMS built entirely in house. I'm the new web developer guy with literally 4 weeks of ColdFusion Experience. What I want to do is add version control to our dynamic pages. Something like what Wordpress does. When you modify a page in Wordpress it makes some database entires and keeps a copy of each page when you save it. So if you create a page and modifiy it 6 times, all in one day you have 7 different versions to roll back if necessary. Is there a easy way to do something similar in Coldfusion?
Please note I'm not talking about source control or version control of actual CFM files, all pages are done on the backend dynamically using SQL.
sure you can. just stash the page content in another database table. you can do that with ColdFusion or via a trigger in the database.
One way (there are many) to do this is to add a column called "version" and a column called "live" in the table where you're storing all of your cms pages.
The column called live is option but might make it easier for your in some ways when starting out.
The column "version" will tell you what revision number of a document in the CMS you have. By a process of elimination you could say the newest one (highest version #) would be the latest and live one. However, you may need to override this some time and turn an old page live, which is what the "live" setting can be set to.
So when you click "edit" on a page, you would take that version that was clicked, and copy it into a new higher version number. It stays as a draft until you click publish (at which time it's written as 'live')..
I hope that helps. This kind of an approach should work okay with most schema designs but I can't say for sure either without seeing it.
Jas' solution works well if most of the changes are to one field, for example the full text of a page of content.
However, if you have many fields, and people only tend to change one or two at a time, a new entry in to the table for each version can quickly get out of hand, with many almost identical versions in the history.
In this case what i like to do is store the changes on a per field basis in a table ChangeHistory. I include the table name, row ID, field name, previous value, new value, and who made the change and when.
This acts as a complete change history for any field in any table. I'm also able to view changes by record, by user, or by field.
For realtime page generation from the database, your best bet are "live" and "versioned" tables. Reason being keeping all data, live and versioned, in one table will negatively impact performance. So if page generation relies on a single SELECT query from the live table you can easily version the result set using ColdFusion's Web Distributed Data eXchange format (wddx) via the tag <cfwddx>. WDDX is a serialized data format that works particularly well with ColdFusion data (sorta like Python's pickle, albeit without the ability to deal with objects).
The versioned table could be as such:
PageID
Created
Data
Where data is the column storing the WDDX.
Note, you could also use built-in JSON support as well for version serialization (serializeJSON & deserializeJSON), but cfwddx tends to be more stable.
I need to find out that how many times and which files are fixed or changed due to a bug between two specific dates in an open source project which uses Trac. I selected Webkit project for that purpose. (https://trac.webkit.org/) However, it can be any open source project.
What can I do for that? How do I start? Do i have to use version control systems like svn or git for intergration? I am kinda newbie for these bug-tracking and issue-tracking systems.
I'm not certain I exactly understand your question, but...
If you browse to the directory containing the files you care about in the Trac site, then click on Revision Log, you will get a list of changesets that affected that directory. You can select the revisions that span the timeframe of interest and then View changes and you will get a summary of the changes, and depending on the size of the changes and the particular Trac configuration, you may get the diffs on that page as well.
Now, that won't tell you how many times those files were changed, just the net changes.
It also won't tell you which bugs those changes were for.
If you really need to filter on what bug, you'll have to determine how that information is tracked by the particular project; and some might not track it directly. The project might include a #123 in the commit message. If you can rely on that, you could use svn log --xml {2009-11-01}:{2009-12-01} ... to get an xml version of the commit log which you could then parse and filter based on the presence of the bug's ticket number in the commit message. From that, you should have a list of the revisions that you care about.