What is the way to get the date a repo was created using libgit2 library?
My initial idea was to get the first commit from a master branch and check its time but I'm not sure if there are better/more straightforward ways of achieving it.
Your approach seems right, but the answer also depends on what you mean by "date a repo was created".
For example, I could create an empty repo with git init and then forget about it for a while and make my first commit a year later. Personally, I don't think that year when nothing was done with the repo is important and I would use the date of the first commit.
If, on the other hand, you think that year important, then you could try using the filesystem commands (sorry, not sure what language you're using) to get file creation dates from the .git directory or some file inside that directory.
Related
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.
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.
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)
A colleague has imported a CVS repository into a pre-existing SVN repository using a cvs2svn dumpfile (like "svnadmin load --parent-dir /path < dumpfile") , which I originally created from the CVS repo.
Now that I'm trying to checkout and build from SVN, I've noticed that some files seem to be missing in the SVN checkout that were present when I checked out the same branch from CVS, although the majority are present. They are mostly but not exclusively binary files (jars and gifs etc.) and I think (though I haven't checked exhaustively) that they are also files that have not been modified on the branch that I'm trying to check out. I should also point out that they don't show up using cvsweb (I would provide a link to the cvsweb documentation but I have no way of knowing its version etc), although they do appear doing a standard checkout of the branch.
If anyone has any idea what's wrong here, or where to start looking to address this, I'd be very grateful! New to SVN so not sure if this is normal! Also, I know I could fairly easily "fix" it by copying over the files but I'd ideally like to keep their revision history so a more complete solution would be preferable. Thanks!
That sounds that the configuration which has been used during the conversion has been wrong. May be a property in svn exists which represent the CVS revision information. If not you're lost..more or less...A good suggestion is to test such migrations and check the contents of the resulting SVN repository...and of course do make backups ...BTW. Are these branches are removed in CVS before?
This is not normal; such files should be handled just fine by cvs2svn. Your best bet is to create a reproducible test case (instructions for doing so are in the cvs2svn FAQ) and report the problem to the cvs2svn users' mailing list.