Specifically I have a repository setup in Launchpad. I need to remove this repository but didn't find any link to do that from launchpad website. I am wondering whether I could do it on my local branch using "bzr". Or I am missing something from the launchpad website to remove it.
To have your entire project deleted from Launchpad, you have to post a "question" on this page:
https://answers.launchpad.net/launchpad/+addquestion
Yeah it's weird. But this seems to be the official way. If you search for the keywords "delete project" on this page you will find many many similar requests:
https://answers.launchpad.net/launchpad
Make sure to include a detailed explanation why you want to do this and that you are aware of the consequences. Otherwise you will get a response along the lines "the community might still use the source code you want to delete" and so on.
Of course they are right, and you should carefully consider whether you really want to remove code that other folks might be using and linking to.
If you are sure you want the project gone, then you can reduce the turnaround time with the Launchpad team by first deleting all your branches. You might not be able to delete the trunk, in that case you can try to force-overwrite it with an empty branch, using these steps:
bzr init empty
cd empty
touch empty.txt
bzr add
bzr commit -m 'dummy commit'
bzr push lp:PROJECT --overwrite
Of course, replace PROJECT with the name of your project. All these steps are necessary to empty the branch. You cannot simply push an empty branch, Bazaar will tell you that No new revisions or tags to push. and the branch will be untouched. You need a completely new revision, like the dummy revision in this example.
If your project has no meaningful source code in it, the Launchpad team should not have any objections to delete it, so you can reduce the turnaround time.
Related
Technology used:
Microsoft Visual Studio Community 2015
VB.NET
GitHub
When i was altering skin in my form to design it, i was having trouble undoing my design to return back to its normal design. And as i go to my Form in Solution Explorer and clicked Undo everything had vanished including my code. I'm having trouble on how to retrieve my code ? Is there a way to retrieve my codes and my design or a garbage collector where i can easily retrieve it?
I would be so happy for your suggestions.I really need your Help.
The only way that you will be able to retrieve your old code at this point is if you did a
git push origin master
(or other branch) to github before you made these changes.
If you haven't use Git Extensions - I would suggest downloading and linking it to your github repo for this project. Git Extensions will give you a nice quick view of all your branches and what is sitting in your local repo.
Provided that you did a
git commit
You will still have your changes saved locally and this can be easily identified using Git Extensions.
If you have made the changes after you did a commit, you will see the old code in Git Extensions. From here you will be able to revert selected lines or all of the files. This is provided, that you had at least one major commit in git before this happened.
Update 1:
Based on your comment on your OP you should still have the original files in git. You should then be able to find your code easily via Git Extensions. You should see a list of changed files and from here you can revert them easily.
Update 2: Based on your comments, it appears that you have completely lost your changes. Git is a change tracker - and based on what you have said you did an Undo Changes on git. This means, that git had reset all the changes that it was tracking and went back to the last commit that you made. There is no way to get your changes back unless you had the files stored on DropBox or something similar where files are tracked on each save of the file. With git, changes made are only stored once committed. If you do an undo changes on the git repo before committing what it actually does is a
git reset
This removes all the changes and reverts it to the last commit.
I've checked and found this. I expect this should deal with your problem. Afterall, as long as you didn't intentionally delete anything, they are still in your target folder where you saved it.
If you checked in your code BEFORE the error on GitHub you can try this:(although I am not certain of community edition as I know it works on Pro and Enterprise).
Go to class in question
Right Click to get context menu
Select Source Control>History
Select a prior version
Right Click Reset>Reset and Delete Changes
This will basically say: "I don't care what happened just take me back to my safe place at this point in time with all affected files!". When performing code I cannot stress the importance to having source control and committing often.
I am trying to understand about branches and tags with TortoiseGit.
I have read a few good tutorials and have managed to create a branch and I can commit changes to that branch and push to BitBucket. And in the tutorial it shows me how to later merge to the master root.
But I don't quite understand the concept of tags. I know how to create tags. But it is getting it all to work.
What I had in my head was that I create a branch XYZ. But this branch is associated with tag 1.2.3 (a version). I thought that I could tie a set of commits (or the whole branch) to a version number. Then when it is merged later I still know what version those changes were for. Can't work it out.
I tried the "Include Tags" when pushing but that created the tag but seems to have applied it to the whole repository.
Am I going about this wrong?
I am looking for best practices using branches in RCS.
I had read the man page for rcs and ci and also browsed at the following links:
http://www.gnu.org/software/rcs/manual/html_node/Concepts.html
http://www.gnu.org/software/rcs/manual/html_node/Quick-tour.html
Suppose i have revision 1.3 on tip of the trunk.
I now want to change file 1.2 (as 1.3 have several other changes I cannot yet use).
I understand I can create branch on revision 1.2 using ci -r1.2.1
My question are the follows:
1. Do I need to set a lock on the file? If so, on which revision?
2. If no lock set, I cannot use -u flag in order to keep the file in my local dir. In case I wish to do so, is it still possible without co the file again?
Side note: I feel RCS does not suit my company needs however migrating to another system is not my decision to make, so currently I need to keep working with it.
I'm looking for much the same thing, but seeing you've had no answers, I'll offer my current practice:
I use branches for development, not for keeping different variants going in parallel. The trunk is reserved for my best, presumably working, code on the and I try not to check in anything there that might break it. I branch the code when I want to start a line of development that will take some time, break it for a while, is an experiment I might have to be abandon, etc.
To start a new line of development I change the default branch to a new branch off the trunk rev that's to be the base of my code, and force a checkin onto that branch, with:
rcs -b1.2.1 foo.cpp
ci -f1.2.1 -l foo.cpp
Now I can dive in to developing the branch, and my next check-ins will go onto the new branch instead of onto the trunk. Whether you lock a revision or not is only relevant to whether you intend to modify the working file.
You're correct that you can't keep both revisions, trunk-tip and branch-tip in the same folder; they have the same file name. But you can check out one of them with a -p switch which forces the output to stdout (instead of to a local file) which you can then redirect into a sub-folder, or to a local file with a unique name.
I have local folder that is branch from formal_versions.
My workflow is:
Mkae changes and than commit them
The integrator merge them in his local branch.
The integrator push its local branch to formal_versions
I use pull to make my local branch identical to formal_versions
This is working fine.
However what should I do in the following scenario:
After pull from formal_versions , I compile the code. As a result , some workspace and obj file are changed (I.E date and time of compilation) and of cource , bazaar explorer inform me on modified files
I again want to make my branch mirror of formal version. What should I do?
A. Why using pull again says that "nothing to pull" even if
I use --overwrite switch ? it is suppose to make my local branch as mirror of the pulled branch...
B. Is my only option is to use revert working tree?
It is generally considered best practice (as well as good for one's sanity) not to version files that are the result of the build process. Executables, shared libraries, and even source files generated from by a 4GL are examples. You can ignore files by using bzr ignore <pattern>, for example bzr ignore *.exe. If the files are already versioned, you will also have to remove them using bzr remove.
bzr pull says there is nothing to pull because the formal version has had no new commits since your last pull.
If you must version the files in question, bzr revert is the only way I know of when bzr pull does not find new revisions. If there had been new revisions in the formal branch, the files should be updated (and will potentially be reported as conflicts).
We use a dev-test-prod branching scheme with bzr 2. I'd like to setup a bzr hook on the prod branch that will reject a push from the test branch. Looking at the bzr docs, this looks doable, but I'm kinda surprised that my searches don't turn up any one having done it, at least not via any of the keywords I've thought to search by. I'm hoping someone has already gotten this working and can share their path to success.
My current thought is to use the pre_change_branch_tip hook to check for the presence of a file on the test branch. If it's present, fail the commit.
You may ask, why test for a file, why not just test the branch name? Because I actually need to handle the case where our developers have branched their devel branch, pulled in the shared test branch and are now (erroneously) pushing that test branch to production instead of pushing their feature branch to production. And it seems a billion times easier to look for a file in the new branch than to try to interrogate the sending branch's lineage.
So has someone done this? seen it done? or do I get to venture out into the uncharted wasteland that is hook development with bzr? :)
your approach should work and the plugin will be quite simple: just raise an exception if the file is present.
(For some sample code you can look at a plugin I wrote that can prevent commits on some conditions https://launchpad.net/bzr-text-checker)