I'm coding a framework along with a project which uses this framework. The project is a Bazaar repository, with the framework in a subfolder below the project.
I want to give the framework a Bazaar repository of its own. How do I do it?
You use the split command:
bzr split sub_folder
This creates an independant tree in the subfolder, which you can now export and work on separately.
Use fast-import plugin (http://bazaar-vcs.org/BzrFastImport):
1) Export all your history to the stream:
bzr fast-export BRANCH > full-history.fi
2) Filter the history to produce new stream:
bzr fast-import-filter -i subfolder full-history.fi > subfolder.fi
3) Recreate new branch with subfolder only:
bzr init-repo .
bzr fast-import subfolder.fi
As far as I know, there is not a way to do this easily with bazaar. One possibility is to take the original project, branch it, and then remove everything unrelated to the framework. You can then move the files in the subdir to the main dir. It's quite a chore, but it is possible to preserve the history.
you will end up with something like:
branch project:
.. other files..
framework/a.file
framework/b.file
framework/c.file
branch framework:
a.file
b.file
c.file
As far as I know, "nested" branches are not support by Bazaar yet. Git supports "submodules", which behave similar to Subversion externals.
I have tried doing this with bzr split, however, this does not work how I expect.
The resulting branch still contains the history of all files from all original directories, and a full checkout retrieves all the files. It appears the only thing that split does is convert the repository to a rich root repository so that this particular tree can be of a certain subdirectory only, but the repository still contains all other directories and other checkouts can still retrieve the whole tree.
I used the method in jamuraa's answer above, and this was much better for me as I didn't have to mess with converting to a new repository type. It also meant that full checkouts/branching from that repository only recreated the files I wanted to.
However, it still had the downside that the repository stored the history of all those 'deleted' files, which meant that it took up more space than necessary (and could be a privacy issue if you don't want people to be able to see older revisions of those 'other' directories).
So, more advice on chopping a Bazaar branch down to only one of its subdirectories while permanently removing history of everything else would be appreciated.
Do a
bzr init .
bzr add .
bzr commit
in the framework directory.
Then you can branch and merge to just that directory.
The bazaar higher up will ignore that directory until you do a join.
Bazaar understands when you do things like
bzr branch . mycopy
bzr branch . myothercopy
The current directories .bzr won't track those subdirectories changes.
It saves you from trying to find a place to put a branch.
Related
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 have been using Bzr for version control of my project over the last few months. I am the sole developer, and currently I just have everything in a single local project directory, to which I commit and which I sync to DriveHQ.
I now have some large-scale experiments in mind which would likely break this main line, so I've been looking into the concepts of branches and shared repositories. So my question is, basically: how should I go about creating a new, shared repository from this already-version-controlled base?
I am familiar with the SVN project structure of trunk, branches and tags, and I'm going to adopt this structure. My plan is to just go ahead and do a fresh init-repo, and copy all my code (plus .bzr) over into the trunk folder. So is this OK? Or is there some way to convert what I have already into a shared repository?
Many thanks in advance for any help.
Christopher
OK, so you have some work directory where your standalone branch is.
You want to create trunk and feature branches in new shared repo.
At first you need to create a shared repository itself:
bzr init-repo /path/to/repo
Now you can put your code to repo/trunk. You can use push, branch or you can copy work and use reconfigure.
cd work; bzr push /path/to/repo/trunk
cd path/to/repo; bzr branch /path/to/work trunk
or copy/move work to /path/to/repo/trunk then cd /path/to/repo/trunk; bzr reconfigure --use-shared
In all cases you'll have branch trunk as a copy of your old work, and this trunk will use shared repository to save the revisions.
You can also look at bzr-colo plugin.
Create a folder outside your current repository.
Call bzr init-repo to create a shared repository
From your working tree push to the newly created shared repo.
You can now work directly on the shared repo
I want to create a bazaar repository and have the .bzr directory not alongside the versioned files.
I'm searching for an option like "--git-dir" in git, or a way to achieve the same thing. Evenctually I'd accept an hack too.
A solution using bzrlib is feasible
Example current structure
project/.bzr
project/foo_versioned_file
project/bar_versioned_file
Wannabe structure
project/foo_versioned_file
project/bar_versioned_file
/unrelated_path/.bzr
There is nothing like --git-dir in bzr, but if you only need avoid having the full history along your working tree, then it's worth to consider using lightweight checkouts. Lightweight checkouts allow you to use only small number of files in .bzr/ directory (but you have to have it anyway) and the real branch with its repository and its history can be kept outside the working tree. So:
bzr branch bzr+ssh://HOST/REPO/BRANCH /unrelated_path
bzr checkout --lightweight /unrelated_path project
I'm just using bzr for my personal project. I have a project folder, and I have several subdirectories. I firstly (mistakenly) did $ bzr init in each subdirectory, and commit many times.
Now I want to $ bzr init in the project directory, including all the subdirectories. But since each subdirectory already has .bzr thing, when I did $ bzr add in the project directory it would not include those subdirectories.
If I just delete all .bzr folder in the subdirectories then it would be possible to add them, but then I would lose all the history. I was wondering if there is any way to merge this?
Maybe my question was not specific enough. I want to pull a folder (for example, 'writing') into the folder "project/writing." Previously writing was the top level folder but I want to make project the top level and have writing as subdirectories.
I tried mkdir project, cd project, bzr init, mkdir writing, and then bzr pull -d ./writing ../writing, but it would pull the files into the project directory, not project/writing directory.
I'm very new to bazaar and sorry if my explanation is confusing.
Thank you,
Joon
see bzr help join:
The result is a combined tree, with the subtree no longer an independent part.
This is marked as a merge of the subtree into the containing tree, and all history is preserved.
I have a Bazaar repository on Host A with multiple branches. This is my main repository.
Until now, I have been doing checkouts on my other machines and committing directly to the main repository. However, now I am consolidating all my work to my laptop and multiple VMs. I need to be working offline regularly. In particular, I need to create/delete/merge branches all while offline.
I was thinking of continuing to have the master on Host A with a clone of the repository on the laptop with each vms doing checkouts of the clone.
Then, when I go offline, I could do bzr unbind on the clone and bzr bind when I am back online.
This failed as soon as I tried to bzr clone since bzr clone only clones a branch(!!!!)
I need some serious help. If Hg would handle this better please let me know (I need Windows support.) However, at this moment I cannot switch from Bazaar as it is too close to some important deadlines.
Thanks in advance!
bzr fundamentally works with one branch / directory (the branch are visible at the file system level), so if you need to clone each branch from your repository (not unlike svn, in a way). Hg, at basic level, works this way too (although you can put several branches in one repository using say named branches).
For DVCS, it is important to distinguish between the following:
Working tree: a versioned set of files (at a given revision)
Branch: a linear set of revisions
Repository: a set of revisions
When you clone locally a directory versioned by bzr, you are copying the repository subset which contains all the revisions in the branch you are cloning, and get the working tree. This assumes you are not asking for a branch wo a working tree nor using a shared repository.
What you want, IIUC, is to clone the full repository with all the branches. There is no 'native' way to do so in bzr I believe, but plugins to help you toward this, like multi-pull and push-repo, to sync multiple branches in one shot.
But I don't understand why that's such a big problem, or the link with working offline: you just clone the branches you want to work on your laptop.