I recently got Phabricator installed and am hoping to use it for our future code reviews. Once issue I'm having is that we have a couple of projects that have never been reviewed/audited, and we're hoping to sit down and audit them.
However, I'm not sure how we can go about doing that using Phabricator. When it comes to auditing, Phabricator seems geared towards auditing individual commits, rather than a full codebase. I liked the ability to browse through the code in Phabricator, highlight sections and comment them (especially since we've got multiple people reviewing the same code, one of which is in a very different timezone), but I can't do that with the regular code viewer.
Is there a way to do a full code audit of an existing project on Phabricator, while still benefitting from the review features they have such as adding comments?
This feature doesn't exist in Phabricator. See the following:
https://secure.phabricator.com/T5744
https://secure.phabricator.com/T4348
Related
Using free, self-managed GitLab
Due to group-level custom project templates available only to paid tiers (even there there are restrictions) I am looking into an alternative solution using a simple project, where
in the code repository each branch provides a template
in the wiki each code repository branch has an entry documenting what the template does
I know that the wiki and the code are actually two separate repositories.
In its nature a template is a construct that offers a pre-made setup for working on a reoccurring task. A group template adds the additional restriction that the reoccurring task applies to more then one individual.
In order to limit tomfoolery and people pushing whatever they want thinking it's worth becoming a group-level template (even though they made something real quick to tackle a problem that has been long forgotten and even they themselves will not work on it ever again) I would like to impose access restrictions to all members. Beside the maintainer/owner all other members are assigned a developer role. All branches are protected so a change of an existing branch or the creation of a new one can only be done through a merge request leading to an assessment whether the committed changes to the repository are actually worthy of becoming a template for the whole group.
Many members of my group have the bad habit of choosing poor names for functionality they have developed (e.g. a script called jennifers_help_script_23.py) and not documenting what was actually implemented. And yes, we are not a software development company but a research institute. :D So in order to improve the documentation and the ability to actually reuse some of the quite useful things that people have developed I would like to make it mandatory for people to provide documentation if they want their stuff to be added to the project.
So the question here is can a user submit a code merge request that also acts as a merge request for a change in the wiki (e.g. user has created a new template, which requires also a new wiki page documenting that template) or the two have to be handled separately given the nature of a GitLab project (wiki separate from code)?
I was thinking maybe each branch (representing a template) will contain a markdown file that will be inserted as a wiki automatically after the merge request has been approved. However I don't know how to automate this. I am currently looking into uploading a file to the wiki using the GitLab API, hoping a can somehow add a trigger in GitLab to execute the "command" upon a successful merge. Needless to say I am quite new to all of this.
I'm an extreme newbie to managing TFS, so please bear with me and know I'll need baby steps. I'll try to be as specific as possible.
I recently inherited an MVC ASP.net website written by a former colleague. Generally he would work directly in the production environment and commit changes as he went along. Obviously that's not good practice, so when I received it I decided to set it up in TFS along with a proper testing and development environment. I created the team project collection, added the existing solution to the collection, set up branching and branch hierarchy, and mapped the work environments. From what I can tell it's set up just like our other site that was configured in TFS before I came on (the person who set it up is long gone).
The issue I'm seeing now is that checking in changes don't seem to be affecting the actual code behind the site. Whether I make the changes in the test branch and then check-in/merge changeset with the production branch, or make the changes directly in production, saving and checking in changes doesn't actually affect the site. If I go into solution explorer and look at the files I just edited, my checked-in changes are not there. Same if I edit a web.config or something, I can then open in up in another text editor and my changes are nowhere to be found.
I followed Microsoft's instructions as closely as I could but clearly I missed something, I just have no idea what.
After using youtrack for quite a while my organization is considering a move to JIRA (because of many reasons). However JIRA doesn't seem to include a youtrack importer/migration out of the box (though there seems to be plenty of importers/migrations the other way around).
Has anyone migrated from youtrack to JIRA and have any experience in this?
Edit:
To anyone who might have this problem later, my final solution ended up something like this:
transfer all "basic" data by hand (user accounts, basic project setup etc)
write a small C# program using the atlassian sdk and the youtrack sdk that transfers from one to the other (creating empty placeholder issues if issues was missing due to someone deleting them in youtrack in order to keep numbering).
This approach worked good enough and I managed to transfer pretty much all data without any loss of any very important data (though of course all timestamps are messed up now, but we saw that as an acceptable loss).
Important to know is that youtrack handles issues moved from one project to another a bit counter-intuitive (they still show up in their first project even when they're moved away from there, but they have an issue id from their new project - a slight wtf when I ran into that the first time).
Also, while the atlassian sdk did allow me to "spoof" the creator of an issue (that is, being logged in as used A and creating an issue while telling the system that it's actually user B who is creating this issue) it does not allow you to do this with comments. So in order to transfer those properly I had to actually loop through the comments and log in with the corresponding new user and post the comments.
Also, attachments from youtrack was a bit annoying to download, so I ended up having to download those "by hand". :/
But all in all, it was relatively pain-free. Some assembly required, some final touch-ups required, but it was all done within a couple of days.
I had the same problem. After a discussion with JIM (Jira Importer) developer, I used YouTrack Rest API and Python script to make JSON files. Then I used JIM JSON import.
With this solution you can import almost all fields from YT - the standard one and files with description, links between issues and projects and so on...
I don't know if I can push it to GitHub, I have to ask my boss - I did it during my work hours.... But of course you can ask me if you want.
The easiest approach is probably to export the data from youtrack into CSV and use the JIRA CSV importer. You may have to modify some of the data to fit the expected format for the CSV importer
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.
Has anyone had luck with removing large amount of issues from a jira database instead of using the frontend? Deleting 60000 issues with the bulktools is not really feasible.
Last time I tried it, the jira went nuts because of its own way of doing indexes.
How about doing a backup to xml, editing the xml, and reimporting?
We got gutsy and did a truncate on the jiraissues table and then use the rebuild index feature on the frontend. It looks like it's working!
This is old, but I see that this question was just edited recently, so to chime in:
Writing directly to the JIRA database is problematic. The reindex feature suggested in the Oct 14 08 answer just rebuilds the Lucene index, so it is unlikely to clean up everything that needs to be cleaned up from the database on a modern JIRA instance. Off the top of my head, this will probably leave data lying around in the following tables, among others:
custom field data (customfieldvalue table)
issue links (issuelink table)
versions and components (nodeassociation table, which contains other stuff too, so be careful!)
remote issue links or wiki mentions (remotelink table)
If one has already done such a manual delete on production, it's always a good idea to run the database integrity checker (YOURJIRAURL/secure/admin/IntegrityChecker!default.jspa) to make sure that nothing got seriously broken.
Fast forwarding to 2014, the best solution is to write a quick shell script that uses the REST API to delete all of the required issues. (The JIRA CLI plugin is usually a good option for automating certain types of tasks too, but as far as I can tell, it does not currently support the deletion of issues, so the REST API is your best bet.)