The client has asked me to submit changes into a different, pre-existing branch in their Perforce repo, but I'm having a tough time figuring out the process for that.
What's the Perforce equivalent of git checkout other-branch? Search engines are failing me; possibly because I'm using Git terminology and/or concepts that don't actually exist in p4.
Once I have the other branch "checked out" or whatever the correct p4 terminology is, can I just create and submit my changesets in the normal way?
Are there any caveats to doing this in the CLI versus p4v? I've mostly been using the latter because I'm a n00b.
Branch specs in Perforce are just different paths. If you have something like
//depot/product/main/...
in your p4 client spec, you'd change it to
//depot/product/branch/...
to get the branch, and use p4 sync to get the files and p4 add/edit/delete/submit as per usual to make changes. You'd merge changes between branches using p4 integrate.
See the Perforce docs for more info.
p4 workspace is the command you want. If you're using p4v you can just add that branch to a new workspace.
You may also find this handy dandy comparison chart useful. http://www.perforce.com/sites/default/files/command-comparison.pdf
Or this cheat sheet: https://jira.atlassian.com/secure/attachment/91198/cheat_sheet.pdf
Related
There is interchanges command in perforce which lists changelists between two branches that have not been integrated with the convenience of a branchspec.
Is there something that shows the changelists that have been integrated something like the reverse of interchanges and also works with a branchspec?
More interested in terminal perforce rather than p4v.
Thanks
My recommended approach would be to do p4 changes on the source, run p4 interchanges between the source and target to get the source changes that have not been integrated, and diff the two to find the ones that have been integrated.
I'll also describe two other approaches that I would not recommend since they're a bit harder (but you might find elements of them useful):
Run p4 changes -i on the target and then run lots of p4 files commands to filter it down to the changes that originated on the source.
Run p4 integrated -b branch, run lots of p4 changes commands to convert the integration records into changelist ranges, and then sort them into a unified list.
Finding out if a changelist has been integrated into another branch in perforce is not simple. 'p4 interchanges' may not report everything as it relies on meta data and may 'think' that some changelists have been integrated.
Consider the case where CL10 was merged to branch B and then the changes were manually reverted via a 'p4 edit' instead of 'p4 undo' on B. Then if you run 'p4 integrate' with CL10 perforce returns with 'already integrated' message even though the code is no longer there (but might need to be).
Perhaps a solution to your question may involve combining ideas from Sam's answer above, 'p4 interchanges' and also running 'p4 integrate [-f]' within a loop to confirm that a set of changelists was indeed integrated. This is some work since the outputs of 'p4 resolve' and 'p4 diff/diff2' need to be considered.
My point is: do not solely rely on 'p4 interchanges'.
We recently moved to git from svn (both using Eclipse). I am in the (perhaps bad) habit of writing my Java code first, getting everything to work and then going back and adding comments. In SVN this was easy. I would just create a Fisheye review with my Jira task. The review would have a list of all the files I changed and methods I added or modified. I would note it and abandon the review. Then I would edit all the files listed and add the comments.
However, Fisheye does not (I believe) work with git. I could do a git status to see the files I changed but the local branch is already updated so it will not list any files. And all it does is tell me I am something like one commit ahead of the remote branch but does not list any files.
Is there some way to see a lit of the files I have changed with git so I can add comments? And when I say I wait for my comments I really mean mostly for added classes and methods. If I do something like add a line or two to a method I will generally add the comment too.
changing comments on git commits is not that easy. Each git commit has a sha-checksum which also includes the previous git commit. If you change a commit you change the current commits sha-checksum. therefore you create a new commit. All following commits of your branch must now be rebased on top of this new commit.
The command line provides the git rebase -i [commitid] where you can do lots of modifications including changing comments on commits. I never did this with a GUI but egit might support that too. Just refer documentation on egits rebase feature.
I found out how to do this.
The "Synchronize Workspace" in eclipse appears to show all the changed files not yet pushed remotely. I have not done any pushes, so this showed me what files changed.
I use svn2git but it fails always on the same line:
My command:
svn2git https://my-svn/proj/ --revision 1000:1001 --username xxx
After one houre this command stoped running and it fails with:
Broken pipe at /usr/lib64/perl5/vendor_perl/SVN/Ra.pm line
623.
What would cause this issue?
For a one-time migration git-svn is not the right tool for conversions of repositories or repository parts. It is a great tool if you want to use Git as frontend for an existing SVN server, but for one-time conversions you should not use git-svn, but svn2git which is much more suited for this use-case.
There are plenty tools called svn2git, the probably best one is the KDE one from https://github.com/svn-all-fast-export/svn2git. I strongly recommend using that svn2git tool. It is the best I know available out there and it is very flexible in what you can do with its rules files.
The svn2git tool you use is based on git-svn and thus suffers from most of the same drawbacks.
You will be easily able to configure svn2gits rule file to produce the result you want from your current SVN layout and you can also tell it to keep empty directories by giving it a commandline option that causes it to put empty .gitignore files in the directories to keep them.
If you are not 100% about the history of your repository, svneverever from http://blog.hartwork.org/?p=763 is a great tool to investigate the history of an SVN repository when migrating it to Git.
Even though git-svn (or the svn2git you used) is easier to start with, here are some further reasons why using the KDE svn2git instead of git-svn is superior, besides its flexibility:
the history is rebuilt much better and cleaner by svn2git (if the correct one is used), this is especially the case for more complex histories with branches and merges and so on
the tags are real tags and not branches in Git
with git-svn the tags contain an extra empty commit which also makes them not part of the branches, so a normal fetch will not get them until you give --tags to the command as by default only tags pointing to fetched branches are fetched also. With the proper svn2git tags are where they belong
if you changed layout in SVN you can easily configure this with svn2git, with git-svn you will loose history eventually
with svn2git you can also split one SVN repository into multiple Git repositories easily
or combine multiple SVN repositories in the same SVN root into one Git repository easily
the conversion is a gazillion times faster with the correct svn2git than with git-svn
You see, there are many reasons why git-svn is worse and the KDE svn2git is superior. :-)
From what I can tell, the "broken pipe" error is due to a problem receiving a file. It might be really big or there may be something else odd about it.
If you run into the error, fortunately in most cases you can simply re-run the git svn clone command or other related command and usually it can seamlessly resume from where it left off.
If you are using git-svn to do a one time migration of an SVN repo to Git, just be sure to follow Atlassian's guide. They have a tool for properly converting the SVN tags to Git tags, but it is a destructive process and you won't be able to use the git repo to sync with SVN anymore, so only do this when you're finally ready to abandon the SVN repo.
I'm using Bazaar quite some time now, but at the moment I'm searching a solution to the following problem:
Assuming you've got several developers with everyone developing in its own branch, like this:
Project
|
|----Branch 1
|
|----Branch 2
|
...
Now, we've got a project manager who wants to have an overview over all branches.
Is there any possibility (using only bzr functions) that he can manage those branches at once?
With "manage", I mean update, commit and perhaps even checkout (last one could perhaps be done with multi-pull but I think this would overwrite existing local data)
Greetings Florian
P.S. I know that this use-case could easily be achieved with SVN (by simply using subdirectories - but without the features of a dvcs) or more or less easily with shell-scripts (something like bzr list-branches|xargs bzr update), but I'd prefer a built-in bzr function
You can see all the branches in a directory tree with:
bzr branches -R /path/to/base/dir
However this works only on the local filesystem. If you need to find branches in a remote system, you need to run the command through ssh or something.
Once you have the list of branches, the manager should branch from them into his local shared repository, preferably configured with the --no-trees option for space efficiency. Existing branches should be pulled instead (using multi-pull for example), removed branches should be removed.
Once he has the branches, the easiest way to overview is using Bazaar Explorer. Open the shared repository location. I especially like the Log button, which will show the tree of logs.
When you say commit... The manager should not commit to the developer branches. If fixes are needed it's better to ask the developer to fix it, otherwise the manager will always have to clean up their mess for them. The manager should only merge other branches to the trunk/main/master. In other words use the gatekeeper workflow.
You can try the bzr-externals plugin or the bzr-scmproj plugin.
I've just discovered, a surprising for me behavior of cvs.
I change file1 localy
During this time people change other unrelated parts of the same file, and commit to the repository
I update my local copy from repository
At this point I expect my local copy of file1 to contain all changes made by others to this file, unless the update above reported a conflict. However, when I do now diff with head, I discover lot's of differences coming from changes made by others in parts of the file that I did not touch at all.
Any ideas? Is this just the limited abilities of cvs to merge? Any wrong setting? Something in my workflow?
CVS has very limited merge facilities. Switch to a modern system such as Git (perhaps via git-cvsimport if the repo maintainer is uncooperative) if you want a better merge experience. See also Best practices for using git with CVS
The final solution is :
1. Save your local code to another place manually
2. Revert the files which may has conflict to the HEAD (most latest) version on CVS server.
3. Add back your change to the Reverted file.
The concept for above solution is to CLEAR UP all the possible issue by REVERT and get a 100% clean version from repository then add back our changes.
It can resolve below issues which caused by code out of date / code base messed up.
CVS commit had a conflict and has not been modified
CVS update failed
CVS not sync