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.
Related
It's been 14 years since I last worked with svn and appearently I have forgotten everything...
I have an existing web-project, consisting of a bunch of php, html, js and other files in a directory tree on a V-Server. Now I want to take these folders under version control and create a copy on my local machine using svn. So I installed subversion according to these instructions: https://www.linuxcloudvps.com/blog/how-to-install-svn-server-on-debian-9/
Using the already-present apache2.
But now I kinda hit a roadblock. If I try svnadmin create on the existing folder, it tells me that is is not empty and does nothing really. All the questions and answers I find here and elsewhere are either
a) focussing on an already existing folder on the local machine
b) assuming more prior knowledge than I have right now aka I don't understand them.
Is there a step-by-step guide for dummies anywhere on how to do this? Or can anyone tell me in laymans terms how to do this?
I can't believe this case never comes up or that it is really very complicated.
At the risk of failing to understand your exact needs, I think you can proceed as follows. I'll use this terms:
Code: it's the unversioned directory at V-Server where you currently have the bunch of php, html, js and other files
Repository: it's the first "special" directory you need to create in order to store your Subversion history and potentially share it with others. There must be one and there can only be one.
Working copy: it's the second "special" directory you need to create in order to work with your php, html, js... files once they are versioned and it'll be linked to a given path and revision of your repository. At a given time there can be zero, one or many of them.
Your code can become a working copy or not, that's up to you, but it can never become a repository:
$ svnadmin create /path/to/code
svnadmin: E200011: Repository creation failed
svnadmin: E200011: Could not create top-level directory
svnadmin: E200011: '/path/to/code' exists and is non-empty
Your repository requires an empty folder but it can be located anywhere you like, as long as you have access to it from the machine you're going to use in your daily work. Access means it's located in your PC (thus you use the file: protocol) or it's reachable through a server you've installed and configured (svn:, http: or https:).
$ svnadmin create /path/to/repo
$ 😎
Your working copies can be created wherever you need to work with your IDE. It can be an empty directory (the usual scenario) or a non-empty one. The checkout command retrieves your files from the repo and puts them in the working copy so, at a later stage, you're able to run a commit command to submit your new and changed files to the repository. As you can figure out it isn't a good idea to create a working copy in random directories because incoming files will mix with existing files. There's however a special situation when it can make sense: when the repository location is new and is still empty. In that case you can choose between two approaches:
If you want code to become a working copy, you can check out right into in and then make an initial commit to upload all files:
$ svn checkout file://path/to/repo /path/to/code
Checked out revision 0.
$ svn add /path/to/code --force
A code/index.php
$ svn commit /path/to/code -m "Import existing codebase"
$ Adding /path/to/code/index.php
$ Transmitting file data .done
$ Committing transaction...
$ Committed revision 1.
If you don't care about code once it's stored in the repository or you want your working copy elsewhere, you can import your files from code and create a working copy in a fresh directory:
$ svn import /path/to/code file://path/to/repo -m "Import existing codebase"
Adding code/index.php
Committing transaction...
Committed revision 1.
$ svn checkout file://path/to/repo fresh
A fresh/index.php
Checked out revision 1.
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.
My group is developing code for use internally as well as to be provided to an external (offsite) group. A baseline version is delivered externally via tar files, but incremental changes (every week or two) are provided with bzr patch files using the "bzr send" command. I've got a bzr repository for development and when a baseline is sent out, we create a reference branch to capture the as-delivered configuration. When a patch file is generated, the reference branch is used as the target for the send command, then the patch file is sent to the external site. My problem is this.... The app I'm developing to automate this process checks consistency between the parent and submit branches as shown with the bzr info command. If the reference branches move due to disk reorganization, the path to the parent will likely not be correct because the branch.conf file uses relative paths to the parent when the branch is created. Is there a way for bazaar to save the path to the parent branch as an absolute path in the branch.conf file?
You can modify the path in branch.conf to be an absolute path (URL) and Bazaar should happily handle that.
Setting the path can either be done by editing it with your favorite editor, or using the command:
bzr config --scope=branch parent_location=URL
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
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.