I am trying to setup directory structure (workspace layout), I need to separate "stable" and "dev" code, and have several releases. I found this Recommended Mercurial repository/folder structure for an SVN user
Is this possible under Bazaar vcs? Any other suggestion to correctly structure directories?
That should work fine with Bazaar. eg.:
my-project (Bazaar shared repository[1])
+ trunk (you can use this for dev if you like)
+ branches (normal directory)
+ v1 (branch for a specific version)
+ v2
+ stable (push the stable stuff in here)
You can use whatever directory structure that you like, but using the svn layout helps to make things consistent for others on your project that have worked with svn.
With Bazaar like with Mercurial you don't really need branches
for each release because if you release off of trunk or stable
then you can just tag it which basically sets a pointer to the revision. Although it is handy to keep a branch per series onto which you can push minor bug fixes to be released as part of the next bugfix release for that series.
[1] Make the base directory for your project a Bazaar shared repository, so that each branch does not keep a copy of the revision history but in stead store all the history in the repository. You can create a Bazaar repository with bzr init-repo /path/to/my-project which will create the directory for you too. All branches pushed or branched under that directory will automatically use the shared repository.
You can also read the official Bazaar documentation on organizing branches and advanced shared repository layouts.
Related
I currently work on solutions / projects within a single GIT repository, in Visual Studio. The commits I make are to a local folder on the Visual Studio server, and then I use the command 'git push origin master' (after having changed directory to my local folder / repository) to push commits to a Gitlab in my company's corporate space. The purpose of this is less about using branches and software development (as I am the only person who does any work on this), and more about having a way to rollback changes and keep a master copy off the server.
I now want a fresh copy of this GIT repository, so I can use that as a new baseline for an application migration. I will still continue to work on the existing repository too.
What is the best way to make a copy of the existing repository, that I can treat as a totally separate thing, without accidently messing up my existing config on the server? Should I do the clone from the Gitlab? Or clone locally and then push that up to the new space in my Gitlab? Honestly, I'm a bit confused at this point about the proper model for this stuff.
....................
Sounds like you'd like to fork the project: keep the existing repo and start a new, separate repo based on the old one.
Browse to your project in Gitlab
On the main repo screen, click "fork" in the top right
Select a new/ the same organisation as you'd like
The project is now forked!
From here, you can clone the fork to your local machine in a new folder. These are now separate projects, and code updates can be added, committed and pushed to the separate repos.
The company I work for uses Clearcase, even though it was EOL'd on the platforms in which we run it years ago. It is ancient and fragile tech, but one thing it does have is a multisite support that allows for the synchronization of air-gapped repos. Because of security issues, we use secure USB sticks to copy packets and take them to the other side, then apply them with scripts.
Developers and DevOps people want to make a business case to migrate to GitLab, but I cannot find any mention of a feature in GitLab that would allow me to do easily do this. There's something about bundles, but the info I have found is years old and it doesn't seem like too many people are using it.
Does GitLab not support this? Simple synchronization of one repo to another over an air gap using some sort of secure media? If so, it's no wonder so many teams are still using ClearCase.
While not exactly easy, air-gap updates of Git repository is possible through the git bundle command.
It produces one file (with all the history, or only the latest commits for an incremental update), that you can:
copy and distribute easily (it is just one file after all)
clone or pull from(!)
This is not tied to GitLab, and can be applied to any Git repository.
From there, I have written before on migration from ClearCase to Git, and I usually:
do not import the full history, only major labels or UCM baselines
split VObs per project, each project being one Git repository
revisit what was versioned in Vobs: some large files/binaries might need to be .gitignore'd in the new Git repository.
You would not "migrate views": they are just workspace (be it static or dynamic). A simple clone of a repository is enough to recreate such a workspace (static here).
I started exploring Gitlab for version control management and I got an issue at the first step itsself. When ever I create a project its creating a new repository. I have few webapplications which are independent to each other. In that case do I need to use different repository for every project.
What I am looking for is what is what and when to use what but not able to find what is repository and what is project in gitlab website as well as through other sources as well.
Also I came across a term submodule, when can it be used. Can I create one global project and have all the webapplications as different submodules.
Can any one please help me in understanding the difference between those 3 and when to use what based on their intended way of usage. Also please help me by pointing to a good learning site where I can get the information of doing basic version control operations in gitlab.
Thanks.
Gitlab manages projects: a project has many features in addition of the Git repo it includes:
issues: powerful, but lightweight issue tracking system.
merge requests: you can review and discuss code before it is merged in the branch of your code.
wiki: separate system for documentation, built right into GitLab
snippets: Snippets are little bits of code or text.
So fear each repo you create, you get additional features in its associated project.
And you can manage users associated to that project.
See GitLab documentation for more.
The Git repo and Git submodule are pure Git notions.
In your case, a submodule might not be needed, unless you want a convenient way to remember the exact versions of different webapp repo, recorded in one parent repo.
But if that is the case, then yes, you can create one global project and have all the webapplications as different submodules.
Each of those submodules would have their own GitLab project (and Git repo).
Currently I am working on opencart site and I would like to integrate opencarts source into my own SVN (https://github.com/opencart/opencart).
The goal is to be able to make my own customizations to core OpenCart files and then, when a new version of open cart is released, integrate there changes into my local version.
I was thinking of source structure as follows:
/trunk/opencart - my custom version of open cart
/vendor/opencart - the current opencart trunk.
The intended workflow would be to pull the latest open cart from their servers, then perform a local merge into my trunk. Currently, I have been struggling to set this up correctly as I am very new to SVN and TortoiseSVN.
My current setup, is Windows7 running TortoiseSVN 1.8.0, Build 24401 - 64 Bit. On my local server I have Ubuntu 13.04 64bit with svn, version 1.7.5 (r1336830).
I managed to setup repository that I can check into and out of, and created an external reference in vendor folder using externals. But I’m struggling to generate the main trunk from this external data. When I try to branch from vendor/opencart to trunk/opencart, it attempts to generated that branch on https://github.com/opencart/opencart rather than my local server. (This rightly fails as the repository is read only).
If I try to perform a merge in SVN on the empty trunk/opencart folder with vendor/opencart I also get problems as there is lack of ancestry in the trunk folder. I've read multiple sources - some say to use my approach, some say I should be using svnsync.
What is the best/simplest approach? Ideally, I would like SVN to pull the latest source, rather than dumping the source into a separate folder.
Re-read about svn:externals in Subversion
Get Subversion URL for this Git repository (SVN can't directly communicate with Git) - it's "Subversion checkout URL" in sidebar, open it in Repo-browser and select needed subtree for you - it can be some branch or trunk, remember full URL to needed subtree (it can be, f.e., https://github.com/opencart/opencart/trunk/upload)
Define, where in your repository you want to mount external repo (let it be /vendor/opencart URL)
Checkout parent of mount-point (or parent of parent for our case, if parent still doesn't exist) into new unrelated to work, Working Copy
Create in WC root new folder (usual, ordinary, standard) vendor
For folder vendor add new svn-propery svn:externals in TSVN's wizard
Commit changes
Check results
PS: you can see (checkout, inspect) at this URL https://subversion.assembla.com/svn/subversion-troubleshoot-b/trunk as sample of simplest use-case for externals (subdirectory lib in trunk is svn:external to another repository subtree)
PPS: At staring point you trunk can be empty, you merge /vendor/opencart in order to get initial vanilla state of code in trunk for your own changes on top of it
This is maybe unusual so let me set the scene:
We have an SVN repo containing our project history - an embedded system based on Linux. The SVN repo contains Linux kernel, U-Boot, busybox etc. sources and all our in-house apps, filesystem and such.
The Linux kernel we have is old and crusty and I am working on porting to the mainline, which is under active development for our platform(s). I am doing the kernel-side work under git and trading patches with "The Community".
I could get things working and take a snapshot of the kernel sources and dump it into SVN, but I'd like to keep the ability to get updates, have local branches and manage patches with git. I could keep two copies of the kernel, one managed by each SCM, but that would be a bit messy. There are also risks of developing and testing using kernel sources managed under git, and forgetting to put those changes into SVN resulting in broken SVN versions where the non-kernel sources are out of sync.
Migrating the entire project to git isn't an option. Managing just the kernel source with git and having a bunch of glue scripts and stored hashes in SVN is possible but it's nicer to have a unified history / diffing ability from SVN for the whole project.
What I'm considering is trying to manage the kernel sources under both SVN and git simultaneously, in the same directory.
As a kernel dev I'd mostly use git and do an SVN commit for internal use when things look good. For other internal users they would be able to get the entire, consistent sources with one SVN checkout, see a unified history, and they could make changes to the kernel sources under SVN. Later I or another git-using person can SVN update to those changes and commit them to git as appropriate.
Some funning around getting git to ignore .svn files and vice versa will have to be done. Also I'm not quite sure how one would take a plain SVN checkout and tell git to start managing the kernel subtree as well, but I'm sure git has some obscure swiss-army-knife options to do it.
So that's my idea du jour. It means most co-workers don't have to worry about git, and we can quietly ignore git and fork away later as needed.
The question here really is, has anyone done something like this, how did it work out, or what alternate solutions did you come up with?
I've done this regularly, and it works great.
The only major thing I needed to do was add the .git folder to the subversion ignore list, and the .svn/ folders to the .gitignore file.