I download code from Gitlab, then create a new branch, update some files and create a review. Then I add a file, execute arc diff --allow-untracked, it reports Usage Exception: There are several revisions which match the working copy:. I execute arc diff --allow-untracked --update D75 to update the existing review, but it creates a new review.
Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
SKIP STAGING No staging area is configured for this repository.
Updating commit message...
Created a new Differential revision:
Revision URI: http://codereview.domain.com/D76
I try many times but it always creates a new revision. How to use arc diff --update?
You shouldn't need --update but you do need to specify the base of your change, so to update the revision associated with the current HEAD, try the following:
arc diffHEAD^
If you've got two commits then you need to use HEAD^^.
To update everything on the current branch:
arc diffparent-branch
So assuming your current branch was branched from master:
arc diffmaster
The arcanist documentation covers this topic in detail, so for a more complete understanding of how arc diff decides which commits to submit, read Arcanist User Guide: Commit Ranges.
Related
I have run the Corda DB Migration tool and created a .jar containing .sql scripts of the tables that represent the States Objects of my CordApps as explained in https://docs.corda.r3.com/database-management.html#database-management-tool
However after putting the .jar in the /cordapps folder of my node, I got an error indicating the Checksum Verification is failing: "liquibase.exception.ValidationFailedException: Validation Failed: 2 change sets check sum..."
Do you know how could I reset the checksum of my objects so that the verification does not fail and I could start the Corda Node successfully?
Thank you
Stan
Truncate your migration related table i.e. databasechangelog & databasechangeloglock. I think truncating only databasechangelog should do the trick for you.
This can happen if you change existing migration scripts which have been run previously. Corda will attempt to check the migration scripts against what has been run and find that the scripts no longer match.
For example: "MyApp" version 1.0 has a migration "init" script that creates table FooBar. On starting the node the table is created and the databasechangelog and databasechangeloglock tables insert a record the migration.
Then "MyApp" version 1.1 comes out which has a modified version of the "init" script. This new script matches the name of the script previously run on version 1.0 but no longer matches the checksum as the content has changed.
Kid101's solution does work but you would only need to delete the relevant entry for the changed script in databasechangelog and databasechangeloglock. Also note that new Corda nodes will skip the original migration and start on version 1.1 which will bypass the issue.
I'm trying to copy the latest artifact from one path to another using Artifactory API.
POST /api/copy/{srcRepoKey}/{srcFilePath}?to=/{targetRepoKey}/{targetFilePath}[&dry=1][&suppressLayouts=0/1(default)][&failFast=0/1]
Let's say I have a few RPMs named: artifact-1.0-1.rpm, artifact-1.0-2.rpm and artifact-1.0-3.rpm.
How to automatically copy the third artifact ?
With the next release of Jfrog's CLI, planned in a couple of weeks, you'll be able to use SORT and LIMIT in the COPY command.
This will allow you to fetch only the latest item\artifact by SORTing by date and LIMITing to the result set to 1.
For now, you can use 2 sequential CURL commands to try and accomplish what you're after:
First use an AQL SEARCH with you're SORT and LIMIT to retrieve the relevant item's path, and then use your COPY command with that path.
Note: the CLI's SORT and LIMIT feature has already been checked in to the CLI's dev branch, so if you wish to use a snapshot you can "download and build" the dev branch from github, and then test if the solution suites you.
I doubt that you can automatically copy all these artifacts in one statement. You can copy the folder but no regex or pattern can defined in copy command.
I have followed every advice on http://r-pkgs.had.co.nz/git.html and on the subsection http://r-pkgs.had.co.nz/git.html#git-branch and I am still getting error.
The steps I need/did (different from what Hadley's page dictates).
grab URL of GitHub repo (e.g, https://github.com/OHDSI/Achilles.git )
create versioned project in RStudio with this URL
set up my global user names for git
select a dev branch here (for example devXYZ)
At this point I got "detached at origin/devXYZ) message.
Per instructions in Hadley book - I tried to do fix this using this command
git push --set-upstream origin devXYZ
but it fails. The error is: origin does not appear to be a git repository or src refspec devXYZ does not match any
I tried fixing it with doing this command (may be wrong)
git remote add origin https://github.com/OHDSI/Achilles.git
I am using windows, latest R, latest RStudio, latest git from https://git-scm.com/download/win
EDIT: I also tried making a new branch using the recommended mechanism but it also fails. The goal is to get instructions where there is not git init and the whole process starts with an URL and new project in RStudio.
The desired future steps to work would be 5. modify and commit into the devXYZ branch.
THIS ONLY APPLIES TO NON-MASTER BRANCHES:
If you are newbie to git - simply don't try to do the git part in R at all.
Instead, use GitHub Desktop or SourceTree.
Point that tool to the desired repo, switch to desired branch
Start RStudio and do any development
Close RStudio and use that external tool to perform any git steps.
FOR MASTER BRANCHES:
integrated RStudio git implementation works great.
I think I might know what the problem is. You're trying to push directly to the main repo. I'm guessing you're not one of the main contributors for that repo so it won't allow you to create a branch there directly. I'm guessing in that book he's probably using his own repository as an example rather than using an existing one
The reason you're getting that error is because that branch doesn't exist on the remote repo so it can't get the reference to it which is inferred from this src refspec devXYZ does not match any
The preferred workflow is to work on a fork of the main repo (basically its your own personal copy of the main repo that is stored on the server). Even if you end up as a contributor at some point I think this is a good workflow to follow
Here's a good explanation on how use the fork workflow. There's other information on stackoverflow as well
Once you've made updates you'd create what's called a pull request to the original repo (commonly referred to as upstream). This basically is a request to merge your changes from the fork into the main repo. This allows the repo owner to review the changes and decide whether to accept them or make changes
Since you're just going over a tutorial I'd say use your fork as the origin wherever its used in the book for now
I have a nexus server version 2.11.1-01 that has a scheduled task setup to run over our snapshots repo to remove snapshots with the minimum snapshot count set to 3 and a retention of 5 days. The scheduled task is showing that it runs, but when I look through our repository there are as many as 26 snapshots for one artifact gav spanning 6 months.
Is there something not configured correctly or a way to find out why it isn't running correctly?
As reported in this nexus Jira:
The snapshot remover removes timestamped snapshots within one version
folder. It does not remove previous versions of snapshots. Note that
it is very common for there to be multiple active versions of
snapshots for a given artifact, some being produced by branch builds
and others by trunk builds.
The "remove if released" option can be used to clean up all snapshots
from a particular version.
Also, as reported in this other Jira, you have to check file naming layout:
Nexus supports Maven2/3 layout only
If you want to delete multiple versions of an artifact, as reported here, you have to use REST apis:
curl -X DELETE -u admin:admin123
http://localhost:8081/nexus/service/local/repositories/releases/content/com/test/project/1.0/
Or, alternatively you can delete them directly from the repository's
local storage on disk. If you delete directly from local storage then
use the REST command to rebuild metadata for the affected path:
curl -X DELETE -u admin:admin123
http://localhost:8081/nexus/service/local/metadata/repositories/snapshots/content/com/test/project/
You'll also need to update the search indexes. If you schedule a
nightly "update indexes" task it will pick up any changes made
directly to the storage area.
Our team is using phabricator to review code. In eclipse, we can post a review request by added Auditors: someone in comment when check in repository. Is there a command patch in comment to update the review request?
arc uses information about the working copy (like the path, branch name, local commit hashes, and local tree hashes, depending on which version control system you are using) to figure out whether you intend to create or update a revision. If it guesses incorrectly, you can force it to either create or update a revision with:
$ arc diff --update <revision>
see http://www.phabricator.com/docs/phabricator/article/Arcanist_User_Guide_arc_diff.html
Use Arcanist, command arc diff and arc update