I tried downloading the bazar repository from launchpad with revision history using:
bzr branch lp:<repo-name>
This repository includes the .bzr directory which contains the revision history.
However launchpad.net also shows an option of downloading the zip file for some repositories.
The zip file does not contain the .bzr directory. It just contains the source snapshot of the latest version.
In github it is possible to download zip files with complete git revision history (ie. the .git directory is present)
I was wondering if this is possible in Launchpad?
No, I don't think Launchpad has such feature. The zip files you see are packaged by the project owners, not something generated or automatic. They could package zip files including the full history but the purpose is usually the opposite: a release version of the project with no history, only the files.
If you want a zipped version of the full history, you have to do it in two steps: branch and then zip up.
The --no-tree flag might be useful for you. Using that flag with the branch command will create only the .bzr directory without the working tree (the project files).
Related
I'm using Intellij Idea community 2019.2 to work with Git repository.
I added a zip file to the repo, but during the commit, I noticed that this file considered as moved from completely different zip file from other directory of the repository.
See the screenshot
But the files are different:
awscli-bundle-1.16.314.zip - 19088950 bytes
awsec2monitor-2-1-3.zip - 15495442 bytes
How can I avoid this behavior?
I'm using a .gitignore file that was recommended for use with CodenameOne projects (See the blog post) and have committed my project to GitHub. Now I want to retrieve that project to a new PC and continue working on it but I'm having endless troubles doing it.
Shai shared a "quick trick" workaround which involves creating a new project then copying the relevant files from a clone of the Git into it, but then it's not a proper clone of the github repo that can be worked on and then synced back up to the remote.
So what I'm asking is: what steps (and troubleshooting resouces) would I use to ensure that:
I am storing the right files to the GitHub Repo to enable success
The IntelliJ Project will work with the retrieved files
I can commit changes back to the Repo going forwards.
Sorry, I'm a bit new to juggling GitHub repos and CN1's plugin structure for Idea has me mystified (I tried merging a new project with a directory which has a clone of the GitHub repo and the CN1 plugin is disabled - can't click on it)
I resorted to using the following .gitignore (using Codepoint One with IntelliJ IDEA):
# macOS
.DS_Store
# build artifacts
/build/
/dist/
/lib/impl/
/native/internal_tmp/
/out/
# idea
/.idea/**/workspace.xml
/.idea/**/tasks.xml
*.iws
With this setting, most of the IntelliJ configs are committed, as well as some binaries: CodeNameOneBuildClient.jar, JavaSE.jar, lib/CLDC11.jar, lib/CodenameOne.jar, lib/CodenameOne_SRC.zip.
This is not optimal (the binaries don't really belong in Git and take about 40 MB combined). But this way I can clone the project on a different machine and start working right away. It also doesn't produce Git diffs on every build — but only if the libs are updated.
IntelliJ/IDEA Codename One projects are nearly identical to NetBeans Codename One project with the one major difference being the additional idea directory. Just copy that directory from a working intelliJ project and add it to the gitignore. The project should work.
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 use Xcode Repositories for working with svn, and today i added a new version to my Core Data Model and tried to commit it. But Xcode through an error:
svn: Commit failed (details follow):
svn: Entry for '/Users/user/Desktop/project/Core Data/Translator.xcdatamodeld/Translator 2.0.xcdatamodel/contents' is marked as 'copied' but is not itself scheduled
for addition. Perhaps you're committing a target that is
inside an unversioned (or not-yet-versioned) directory?
I think that the problem is that svn treates xcdatamodel as a dolder, and since it is changed it doesn's under version control anymore. But what should i do then? Don't commit new models and transfer it manually?)
I would recommend writing a subversion checkout/commit hook that would create a zip or tar archive of the Translator.xcdatamodeld directory, and then check that in. The actual xcdatamodeld directory would be ignored. (It would probably be best not to compress the archive, since compressing will just make it harder for svn to compute diffs and make your repository larger.)
The problem is that when you start with the first data model, Xcode creates a file, let's say:
myProject.xcdatamodeld
Let's say that you create, via menu Editor > Add Model Version, a second version of the model named _myProject_v2_. What Xcode actually does is: it creates a folder, named as your original model, and copies the original model in a subfolder, then creates a second subfolder with a file containing the new version:
myProject.xcdatamodeld
|
+- myProject.xcdatamodel
| |
| +- contents (a file containing the actual model)
|
+- myProject_v2.xcdatamodel
|
+- contents (a file containing the 2nd version of the model)
So SVN gets confused, because what he thinks is a file (the original myProject.xcdatamodeld) and which is stored in SVN, is now a folder, with subfolders.
And moreover, these subfolders, being created by XCode, gets eventually their hidden .svn folder.. so my solution is:
delete folder myProject.xcdatamodeld from SVN
do a commit of the rest
close Xcode and rename your folder project: eh: _projectFolder_old_
do a checkout of the project, which hopefully will not have a myProject.xcdatamodeld
from within xcode, create a bogus data model named myProject. Don't create anything in the model, it's useless
version it, with Editor > Add Model Version
close XCode
open in Finder your old datamodel in myProject.xcdatamodeld (right mouse button, Show package contents)
open in Finder your original model and copy the contents file from *projectFolder_old/myProject.xcdatamodeld/myProject.xcdatamodel* to the new project: projectFolder/myProject.xcdatamodeld/myProject.xcdatamodel (you will need to do a couple of Show Package Contents
repeat for your second version, copy the contents file from *projectFolder_old/myProject.xcdatamodeld/myProject_v2.xcdatamodel* to the new project: *projectFolder/myProject.xcdatamodeld/myProject_v2.xcdatamodel*
reopen Xcode and check everything is correct
add to svn the files, if not already added, and do a commit