I want to get the state of a repository as of a given date, view the files and then subsequently view the history of those files independently in Team Foundation Version Control (TFVC).
I know I can "Get this Version", but that's not what I want. I'm not looking to change my local system or download and change my working directories contents. Even if I do a "Get this Version" and view the contents of a file that exists which was replaced later down the line with a file of the same name (a "Delete" followed by an "Add" in a different commit), the history of the file I'm attempting to view seems to only follow the ancestry of the most recent file, not the older one in question.
Ex:
Feb: ADD Repo\MyFile.cs
March MODIFY Repo\MyFile.cs
April: DELETE Repo\MyFile.cs
May: ADD Repo\MyFile.cs
June: MODIFY Repo\MyFile.cs
If I do a "Get This Version" at revision #2 and then, after getting that version, find the file MyFile.cs in my project attempt to view the history of the file, I only see history from revisions #4 and #5. I want to be able to get insight into revisions #1 - #3 and see that ancestry clearly.
Is there a way to do this?
Related
The problem:
I'm using bitbucket stash (server) API in a script for my project with the {path} api method:
/rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/browse/{path:.*}
The idea was to save versions of config files in a repository (version01-versionXX for every config). But those configs have the same structure with different names and parameters,
so when I push a new config with a commit message like 'version01' without specifying any sourceCommitId, bitbucket automatically adds a parent commit from the last file with the same structure (if it exists). As a result, in this new file's history I'm getting several 'version01' commits, which is not what I was intended to have.
What I've tried:
If I do specify sourceCommitId as the initial or the last commit on the branch, I get an error message since the file doesn't exist on this commit.
I've tried to experiment with empty sourceBranch parameter, but still some parent commit appears.
The only idea I came up with is to create a new branch for every config, but this seems like overkill to me.
All attempts to find a method for editing file commit history via API also failed.
At the moment as a work around I create every config file with its name as the only line of its content and then change it to the structure I need. This works so far, but doesn't look like a good solution to me and requires 2 API requests instead of one.
Is there a better way to prevent BitBucket from treating those new files as copies of old ones?
Container Name Generator
According to names-generator.go :
Docker, starting from 0.7.x, generates names from notable scientists and hackers.
History
The commit history of this file only goes back to 2013:
Questions
What did docker use prior to 0.7.x? Animal names?
Is that list (or older docker source code) available somewhere?
In the GitHub UI, click "History" at the top-right corner of that file's page. That takes you to a listing of all commits that have ever touched this file. There aren't actually that many; the oldest, which you cite in the question, is commit a009d4a. Click on its commit hash in the UI.
That takes you to a page that shows that commit. That commit is mostly a pair of file renames. Note what got renamed.
That also commit has 1 parent 3fc9de3. Click on that commit hash, and then the "Browse Files" button at the top-right corner of the UI. You are now browsing the Docker source tree at the commit immediately before the rename.
The commit description and diff reference a package namesgenerator that got renamed. You can find that in the top-level directory listing in the pre-rename commit. Click into that, and then click "History" on that page to find the very early history of the name generator.
From this history we can find out:
The name generator didn't exist at all more than 2 months before the rename commit you cite; its first commit was on 28 October 2013.
The very first version of it generated names of the form color_animal. Its second commit added more colors and animals, so it would allow names like brown_bear, red_bird, yellow_duck, and so on.
The mood_inventor scheme was introduced in the fourth commit on 23 November 2013.
These pairs were required to have cool inventor names, be easy to remember, be mildly funny on occasion, and be politically correct, though the heuristics for determining these were rather limited (all four conditions were fixed to true). These requirements were removed in 2016 (since the test actually did nothing).
Looking at the Docker CHANGELOG.md, Docker 0.6.5 added the initial "Containers can now be named" with the first color_animal scheme, 0.6.6 "Add[ed] some more colors and animals to increase the pool of generated names", and 0.7.0 added "Container naming: organize your containers by giving them memorable names" with the modern scheme.
A colleague sent me a Gerrrit code review "draft" (I suppose via "refs/drafts/master" instead of "refs/for/master") and then left on holiday. Without downloading the patch and submitting it myself, how can I promote his draft to a full regular code-review so I can approve it & submit it for merging?
I think this is a similar question, but it's for git-review, not Gerrit. Also I'm interested in doing it from the Gerrit web GUI if at all possible. And I don't see a "Publish" button on my Gerrit web GUI for that draft. (And currently it doesn't say anything about merge conflicts, as long as I hurry....)
If I click on the "Patch Sets" link in the top right of the GUI, this is what I see:
In the top left it says "Change 58358 - Draft", and in the middle of the window it shows this:
Only the change owner can publish a draft patch set. Using the UI's cherry-pick option as described in other answers won't work because the cherry-pick implementation preserves the draft status on the new change or patch set.
As far as I know the only way to force the change into NEW state is to manually download the commit and push a new patch set using refs/for/master instead of refs/drafts/master.
Note that if you're not rebasing the change onto a new parent at the same time, you might need to slightly edit the commit message to make gerrit accept it. Otherwise it'll reject with no new changes.
If your colleague add you as reviewer, you can. You can cherry-pick this commit.
Click on download link at the right-top corner, and there are aliases for commands above.
But as you updated your question, you don't want to check out and manually push or cherry pick to master branch. You can use cherry-pick\merge button on ui, if you are confident in this mr, and it should be on master branch. Also you can publish this commit for other reviewers.
p.s. updated (you can cherry-pick, merge, publish via UI)
Do the following procedure:
1) Go to the draft change page
2) Click on Cherry Pick button
3) Write "master" in the Cherry Pick to Branch field
4) Adjust the Cherry Pick Commit Message if needed
5) Click on Cherry Pick Change button
It'll be created a NEW CHANGE cherry-picked from the draft change. Go to the new change page and follow the regular Gerrit process (review, approve, submit). The original draft change can be abandoned or deleted.
So I have been asked to create a job on a Jenkins system that is on the university servers. The problem is I was asked to create it in a specific folder. However I accidentally created in the root folder. Is there a way to move the job from the root to the specific folder or do I have to delete it and create a new one?
There is a move option on the GUI:
Stand on the little triangle near the job you want to move/copy/delete, and on the popup menu - choose the wanted operation. On move you can move to another folder.
But, There is also an open issue about this (opened on 2016):
https://issues.jenkins-ci.org/browse/JENKINS-35093
I had to restart Jenkins after doing it to a job with some history.
So maybe re-create/copy and delete is a better solution (but no history is saved).
Go to your job's configuration page and from 'Advanced Project Options' check 'Use custom workspace'. Enter the path of the directory where you want the files to be created.
The story is like this:
1. I submit a group of files to the server with p4 gui, and some of the files are new (mark for add), e.g: a.cpp
2. But I need to back out the files down to some errors. So I back out and submit.
3. check out the files
3. Now, a.cpp become to a.cpp(0/2). when I submit the files, come out the following errors:
Out of date ....
4. My question is , How can I submit the files again? Thanks. or Can I force to submit the files no matter what errors come?
You give very little information in your question, so this is just a guess: it seems that you are having trouble trying to add a.cpp because it has already been submitted by another changelist.
It looks like some other changelist has already submitted a.cpp, and has in fact submitted a second revision of it. So
a.cpp(0/2)
is trying to tell you that you have a.cpp open for add (you're at revision 0), while the repository records a.cpp at revision 2.
So you need to convert your add request to an edit request, as follows;
Make a copy of your a.cpp file somewhere safe
Revert a.cpp, so you no longer have it open
Sync a.cpp, to get revision #2 in your workspace
Open a.cpp for edit, so that you can change it
Copy your saved copy of a.cpp from step (1) into this workspace directory
Diff your copy to see what your changes are
If you're satisfied with the changes, submit them