Perforce noob here - I have a file on a shelf which I want to unshelve to run a few things, however the file is exclusively checked out on another machine. Ideally what I want to do is unshelve the file locally, do a few things, then toss out my local changes.
I considered using p4 print and p4 copy but they don't seem to work as required - e.g. copy seems to copy files between depot paths.
How can I unshelve and ignore the lock? Alternatively, how can I download the file from the shelve to overwrite it locally?
Two options:
Use p4 print FILE#=SHELF to get the content of the file. This is very straightforward for one file but will be annoying for multiple files.
Create a new branch/stream and unshelve it there; the exclusive lock isn't global across branches so you can do whatever you want in your own branch.
With streams option 2 looks like:
p4 switch -c my-new-stream
p4 unshelve -S my-new-stream -s SHELF
With manual branch specs it looks more like (assuming your client maps everything, if not there's an extra step of adding the new branch to your client mapping):
p4 branch my-new-branch
(fill in a view mapping the current branch to your new branch)
p4 copy -b my-new-branch
p4 submit
p4 unshelve -b my-new-branch -s SHELF
Related
I bzr pulled from a repo. Some of the new files (related to a TeX documentation) in the repo apparently could not be placed in the corresponding local dir since there was some kind of lock. I had TeXStudio open, I am not sure if it locked a directory.
The pull operation reported an error (which I missed since the shell window was later closed).
Now the status of my local dirs is:
bzr pull shows the system is up to date.
$ bzr pull
Using saved parent location: XXXXX
No revisions or tags to pull.
The local dir is empty. There should be some files (I actually have them in the local dir in another computer).
I guess .bzr contains the required info.
Is there any way to fix the local copy?
You probably need to run:
bzr co
(without any arguments)
To create a working tree for the current branch.
I'm new to JavaFX 8 and the IntelliJ IDE. I have a JavaFX8 project that works but not as I would like. I'd like to try another approach but the substantial changes may not work. I don't want to loose code I have working.
To save code I have working, I've been creating a new project and then locally copying all the folders(.idea, out, src) and files except .iml, of the working project into the appropriate folders in the new project with the newly generated .iml.
This always seems to work but is it proper procedure?
I'm not on a team of developers and have yet to learn Git/GitHub.
Please advise. Thanks.
Maybe you should learn how to use a Version Control System like Git, then you can create a project repository and have different branches for things you want to try out. Keeping the working code in your master branch will prevent you loosing your working code. Also, when using a vcs you can always revert to versions of your code that have been working. The IntelliJ Idea IDE has perfect support for working with all different types of version control systems. If you don't want to learn any forms of vcs then there is no other way to "backup" your working code.
Is it proper procedure? It's probably not how most people would go about achieving what you want to achieve but it's certainly workable. If you wanted to stick with that for simplicity now, I'd copy the whole directory structure, delete the .idea and .iml files, and then create a new project in IntelliJ on that clean copy: IntelliJ will automatically set up folder structure based on the existing source without you having to go through any additional manual setup.
If you're willing to experiment with the git route, to achieve the basics of what you want to achieve is not very complicated and I've written a small quick-start below. IntelliJ offers very good support for Git, and once your repository is created you can do everything you need from the IDE. I'm going to assume you're working on Windows, although the steps shouldn't be too far removed on other platforms.
Install Git
You can download and install Git from https://git-scm.com/download/win, which will install a command shell called Git Bash.
One-off setup for your project
Open up git bash and go into the directory containing your source. Rather than seeing separate drives as Windows does, Git Bash assumes there is a logical 'root' directory under which all your files are accessible. Your C: drive will be /c. To move around you can use cd to change directory (using / instead of ) and ls to list files instead of using dir.
Assuming your source code is in C:\projects\myproject:
cd /c/projects/myproject
git init
The second line above creates a git repository in that directory. This doesn't affect your code, it just creates a folder called .git that contains all of the book-keeping information.
You don't want to have every file under version control - in particular you don't want your build outputs. You need to set up a file in your project directory called .gitignore which tells git which files and directories should be ignored. As a starting point you can copy https://github.com/github/gitignore/blob/master/Java.gitignore and rename the file to .gitignore
Basic Commands and committing your initial version
There are a small number of basic commands:
git status
Running git status will tell you which files have been modified, which are not under version control, and which files have been added to the staging area to be committed next time.
git add path/to/file
This adds a file to the staging area waiting to be committed. You can add multiple files to the staging area before committing them in one go.
git commit -m "description of your change"
This commits all of the staged files as a new version, which the specified commit message.
If you go into your project directory, do a git status and check through the list to make sure there's nothing you don't want to have under version control, then you can do git add . to add everything to the staging area and git commit -m "Check in initial version of the source code" to commit it to the repository.
After you've committed, you can run
git log
To see a history of all of the changes. IntelliJ has a view that will show you the same thing.
Creating an experimental branch
This is where git shines; if you want to try something experimental you can create a branch of your project while allowing git to preserve the original version.
git checkout -b experiment1
Will create and switch to a branch called experiment1. You can delete, rename, move, rewrite and develop whatever you like on this branch. The changes you commit will be independent of your original working version.
You can switch back to your original version (preserving all of the changes you've committed on that branch) using:
git checkout master
Where master is just the name of the default branch created when you ran git init. The experimental version will still be there and can be switched to again using git checkout experiment1 or from IntelliJ using the branch selection in the bottom right corner of the status bar.
If you decide that the changes you've made in experiment1 are to become your new "good" version, you can merge them back into the master branch and repeat the cycle from there.
I am trying to use bzr for installing OpenERP. The problem is that I have a very slow internet connection.
When I try "sudo bzr branch lp:openobject-addons/7.0 addons" it takes too much time and sometimes the connection is broken. My questions are:
How can I resume the process on connection broken since every time I repeat the command I get an error "folder already exists..."
Is there any way I can restore a local backup of the files and folder structure and then just compare those files/folders with the files on the server and just upgrade the changed files/folders via bzr? This could be a solution for my slow internet connection.
If I sucessfully download all the files from a branch, which command should I use later to verify if there is any change on the files on the server and if so, how can I update this changes?
Thank you very much
Best regards
Paulo
What takes a lot of time and bandwidth is not transferring the OpenERP addons files themselves, but the repository containing the whole versioning history. It has grown quite big over the years, due to the number of commits as well as the daily translation updates exported by Launchpad.
Answering your points one by one:
If you don't actually need the revision history, you can grab a "lightweight checkout" of the addons instead of a full checkout, by using this command:
bzr checkout --lightweight lp:openobject-addons/7.0 addons
It will be much faster but will only get the files, not the history. You'll still be able to use bzr pull to grab the latest changes from upstream. See also the doc about bzr checkout.
Now if you still want a full checkout you can use the trick of grabbing only a few hundred revisions at a time (there are about 9000 in addons 7.0 right now), so you can resume at any time even after a timeout:
$ bzr branch lp:openobject-addons/7.0 addons -r 100 # grab first 100 revs
$ cd addons
$ bzr pull -r 1000
$ bzr pull -r 2000
$ bzr pull -r 3000
$ ...
There's no easy way to completely bootstrap a full addons checkout unless you manage to perform a full checkout on another machine or internet connection, in which case you should be able to simply transfer the directory (most importantly the .bzr it contains) on any other machine.
In order to see the difference between a local branch/checkout and another repository you can use bzr missing, for example bzr missing lp:openobject-addons/7.0. You can then grab the latest changes from that repository (provided it is compatible with yours) using bzr pull.
Now you should really have a look at the bzr documentation in order to get more information about the typical use cases. The documentation also contains a "bzr cheat sheet" that may help you.
Unfortunately I don't think you could resume a bzr branching.
OpenERP's official website does provide source code nightly builds,
but they use a different structure. I'd recommend you ask a friend
who has a faster Internet connection to bzr branch the source code
repositories and transfer them to you.
You could do bzr pull to get the latest changes and merge them
I maintains two branches master and pathogen for my vim scripts. Both of them have their respective vimrc files. Now I want to merge both of them together and save it as vimrc of branch pathogen.
What I am doing now is checking-out vimrc from master branch and append it to the vimrc of pathogen. Is there a cooler way to do it?
$ git pull origin pathogen
Should do the trick
Is there a way for Bazaar to be able to automatically detect changes (adds, removes, renames, etc.) made to part of the working directory and automatically apply them?
I have a directory tree in my repository which is generated by another process so I can't do all the bzr add, bzr delete, and bzr rename commands as the files are changing. Instead, I would like a way to have bzr notice all the changes and apply them after this process is run.
The only way I can think of doing this right now is running bzr status and then manually (or by writing a script) run bzr add and bzr delete on all the files listed. This will work but I am hoping there is an automated method that could also determine if a file was renamed (an added file has the same contents of a delete file).
You don't need to explicitly mark files as deleted. And bzr can detect renames (either with automv plugin or with builtin functionality):
bzr mv --auto
Note that if you moved the files to a new folder that you just created, you have to version it, but without adding its children (--no-recurse), othervise mv --auto might fail to detect renames:
bzr add --no-recurse newfolder
Then you need to add all files which are not part of renames:
bzr add subdir/
Could you just call bzr add * at the end of the process? Your subsequent commit should take care of all additions and removals. This will not detect if a file was renamed/moved by some process other than bzr mv (and I am unaware of any way to do so).
It looks like the automv plug-in will automatically detect renames and moves. This, along with bzr add * should do the trick.