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
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?
I do alot of personal development tweaks on code on my side, like adding an account automatically, opening up sublime in a certain way when there's an exception (with a rescue_from from an ApplicationController), and other misc tweaks I think are very useful for me but that I don't think I should/other colleagues would like to have committed.
I searched around a bit and supposedly git doesn't have any way to ignore single file lines.
I figured a solution (albeit probably a little complicated and involving markup) would be using Git pre-commit hooks, but... doesn't sound very neat to me.
How can I keep personal code tweaks on my side, inside existing, committed files, without manually stashing/restoring them between commits, while also being branch-independent?
I searched around a bit and supposedly git doesn't have any way to ignore single file lines.
Good news you can do it.
How?
You will use something called hunk in git.
Hunk what?
Hunk allow you to choose which changes you want to add to the staging area and then committing them. You can choose any part of the file to add (as long as its a single change) or not to add.
Once you have chosen your changes to commit you will "leave" the changes you don't wish to commit in your working directory.
You can then choose if you want this file to be tracked as modified or not withe the help of the assume-unchanged flag.
Here is a sample code for you.
# make any changes to any given file
# add the file with the `-p` flag.
git add -p
# now you can choose form the following options what you want to do.
# usually you will use the `s` for splitting up your changes.
git add -P
Using git add -p to add only parts of changes which you will choose to commit.
You can choose which changes you wish to add (picking the changes) and not committing them all.
# once you done editing you will have 2 copies of the file
# (assuming you did not add all the changes)
# one file with the "private" changes in your working dir
# and the "public" changes waiting for commit in the staging area.
Add the file to .gitignore file
This will ignore the file and any changes made to it.
--assume-unchaged
Raise the --assume-unchaged flag on this file so it will stop tracking changes on this file
Using method (2) will tell git to ignore this file even when ts already committed.
It will allow you to modify the file without having to commit it to the repository.
git-update-index
--[no-]assume-unchanged
When this flag is specified, the object names recorded for the paths are not updated. Instead, this option sets/unsets the "assume unchanged" bit for the paths. When the "assume unchanged" bit is on, the user promises not to change the file and allows Git to assume that the working tree file matches what is recorded in the index. If you want to change the working tree file, you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).
Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.
We have a solution stored in TFS that deploys to SharePoint. As part of the solution we have a config file that has a path to a specific site. The problem is this path changes dependent on the users dev machine e.g
<site>devmachine1/somesite</site>
<site>devmachine2/somesite</site>
This can obviously be updated to work locally after a check out however when the file gets checked back in it will be incorrect on the next users machine if they do a Get. Is there a way that the file can be excluded or a script can be run to update the path when checked back in or out?
The best option I'd to rationalist all of the developer workstations.
I would do this by adding an identical entry to the hosts file that hard coded the name of the Sharepoint, allowing you to have the same config file work on every dev machine.
Make it dynamic by having a pre build instruction that adds the host, that way any developer can get and build.
You can use a custom check-in policy to update back the file when is checked-in. See here
I have a problem with "p4 edit" command, it opens two files for me which creates mess when I try to submit my changes.
Here is example output of p4 edit:
p4 edit //depot/project/myproject/Test.java
//depot/project/myproject/Test.java#24 - currently opened for edit
//depot/project/myproject/Test.java#20 - currently opened for edit
I can not figure out why this happens, only idea I have is to check if I have wrong client specification, but it is correct. I map one depot folder to exactly one client folder.
Regards, Victor
I think you might have somehow got two copies of Test.java mapped to different local files in your Perforce workspace. To test this theory, run
p4 have //depot/project/myproject/Test.java
Then, if you do have two versions in different directories, run
p4 client
and edit the paths in your client so that you only map //depot/project/myproject/ to a single local directory.
I've got a need to checkout an entire source tree out of one server and check it into another server. I'm attempting to script this into a final builder script, but am running into some snags. I'm able to check everything out, but when I attempt to check it into the new server it tells me there are no pending changes. Obviously I'm missing something if this is even possible.
Anyone done something similar to this or know of a way I might accomplish this?
One more thing, if the src is empty on server 2 would I have to manually add the files before I can update them?
I would guess that the reason that TFS is saying no pending changes is that you haven't checked out the files from Server 2. This could get kind of ugly using a single directory, so I would recommend trying this:
Get (latest or specific version) from server 1 to
C:\Server1Files...
Get and Check out for edit everything from server 2 to
C:\Server2Files...
Copy from C:\Server1iles1\ to C:\Server2Files
Check in from C:\Server2Files
I think TFS is going to complain if you try to use a single directory here, as it would see the same directory mapped to two different workspaces (even though they're on different instances of TFS).