Generally,our fixes/patches for any bugs involves changes in multiple files and we will commit all these files in a single shot.
In SVN, for each commit (may involve multiple files),it will increment revision number of whole repository by one. So, we can easily link all the multiple files that went in a single commit.
Now the difficulty with the same case in CVS is that it will increment the revision numbers of all the files individually. Let's say if a commit involves the following files:
file1.c //revision assigned as part of this commit..1.5.10.2
file2.c //revision assigned as part of this commit..1.41.10.1
and the comment given for this commit is "First Bug Fix".
Now, the only way to get all files checked-in as part of this commit is by searching through all the cvs logs for comment "First Bug Fix" and hopefully it will return only the two file revisions mentioned above.
Please share your views on if there is any better way in CVS to keep track of all files checked-in in a single commit instead of relaying on comment given as part of commit.
I think CVSps might do what you are looking for.
"CVSps is a program for generating 'patchset' information from a CVS repository. A patchset in this case is defined as a set of changes made to a collection of files, and all committed at the same time (using a single 'cvs commit' command). This information is valuable to seeing the big picture of the evolution of a cvs project. While cvs tracks revision information, it is often difficult to see what changes were committed 'atomically' to the repository."
This cvsps relies on cvs client. Make sure you have proper version of cvs which supports rlog command (1.1.1)
CVS does not have inherent support for "transactions".
You need some additional glue to do this. Fortunately, this has all been done for you and is available in a very nice extension called "cvszilla".
The home page is here:
http://www.nyetwork.org/wiki/CVSZilla
This also ties in to CVSweb, which is a great way to browse through your CVS modules via a web-based GUI.
Perhaps the ANT CvsChangeLog Task is another choice. See http://ant.apache.org/manual/Tasks/changelog.html . It provides date and time for a checkin message. You can produce nice reports with XSLT - try the example at the bottom of the ANT manual page.
I know it's late for an answer, but perhaps other users come across this like I did (searching) and appreciate the ANT integration.
OK, I just installed cvsps and ran it from the top level. Here's a sample of the output... this is one of the few hundred patch sets on my module. Note that indeed this does work across different directory trees.
---------------------
PatchSet 221
Date: 2009/04/22 22:09:37
Author: jlove-ext
Branch: HEAD
Tag: LCA_v1_0_0_0_v6
Log:
Bug: 45562
Check the length of strings in messages. Namely:
* Logical server IDs cannot be more than 18 characters (forcing a
TCSE protocol requirement).
* Overall 'sid' (filter) search string length cannot be more than
500 (this is actually more than the technical maximum messages are
allowed, but is close).
Alarm messages and are now not going to crash either as the alarm text
is shortened if necessary by the LCA.
Members:
catalogue/extractCmnAlarms.pl:1.2->1.3
programs/ldapControlAgent/LcaCommon.h:1.18->1.19
programs/ldapControlAgent/LcaUtils.cc:1.20->1.21
programs/ldapControlAgent/LcaUtils.h:1.6->1.7
programs/ldapControlAgent/LdapSession.cc:1.61->1.62
tests/cts-45562.txt:INITIAL->1.1
So, this may indeed do what you want. Nice one, Joakim. However, as mentioned, CVSzilla does much more than this:
Web-browsable CVS repositories (via CVSweb).
Web-browsable transactions.
Supports transactions across modules.
Generates CVS commands (using 'cvs -j') to merge patchsets onto other branches.
Integration with bugzilla (transactions are automatically registered against bugs).
If all you want is just the patchset info, go with cvsps. If you're looking to use CVS on large projects over a long period of time and are thinking about using bugzilla for your bug-tracking, then I would suggest looking into CVSzilla.
This also could be useful:
http://code.google.com/a/eclipselabs.org/p/changelog/
Related
I have two .mdb files with one being a copy of the other. When there are made changes to the original mdb i want to merge them into my copy, which itself may have changed meanwhile.
As I require to use access 2002 Version Theres a lack of helpful plugins but Id be fine with Just using SaveAsText and LoadFromText Methods.
The Problem is - when i change the file i generated with SaveAsText, the checksum at the top of the file does Not Match the Content anymore and Access throws an Error 3011 when I Try to do LoadFromText.
Does anyone know about a way to work around this issue?
As in not only the major changes maybe the installed dependencies and all before a release without checking one by one?
Since Git won't know which commits are important to you, you'll have to first define your own set of guidelines/format on how you write your commit messages, which you can then use later on to easily differentiate all the commits made for a particular development period.
For example:
If it's a bug fix, prepend the commit message with a "[bugfix]"
If it's a new feature, prepend the commit message with a "[feature]"
If it's a project setup change, prepend the commit message with a "[migration]"
Then, once all the branches have been merged to the main branch (let's say it's develop), checkout the develop branch and use git log --grep=<PATTERN> to identify a specific set of commits.
For example, if you only need the bug fix commits, do a:
git log --grep="bugfix"
which will show you all the commits with "bugfix" in the commit message.
If you only need the commits for a specific period, you can use the --since=<date> option:
git log --since="2017-06-01" --grep="bugfix"
If you want a formatted list (something that you can easily output to some sort of release notes, I assume), you can use the --format=<format> option:
git log --since="2017-06-01" --grep="bugfix" --format="(%ci) %h : %s"
The command above will give you something like this:
(2017-06-18 18:26:36 +0800) 63f330f : [bugfix] prevent crash when dialog is sent to background
(2017-07-01 10:03:40 +0800) cdcbd91 : [bugfix] remove extra row at the end of the list
You can check out the other format options from the complete git log docs.
Basically, it will all depend on your commit message format.
As a tip, you can look into using a commit.template to make it easier to format your commit messages.
commit.template
If you set this to the path of a file on your system,
Git will use that file as the default message when you commit. For
instance, suppose you create a template file at ~/.gitmessage.txt that
looks like this:
subject line
what happened
[ticket: X]
Short version
When I compare two forks on Github, it does not compare the latest states, but the current state of the base fork with the last common commit (or am I wrong?); so how can I compare the latest states/heads on Github?
Longer version
I am trying to compare two repositories on Github.
It does not seem to compare the latest states of both repository. Instead, it compares:
the base fork as it was when both repositories where identical (last common commit?)
with
the head fork as it is now.
You can see this in the Github's fork comparison example, it says there are no changes between those two repositories, but there are now very different.
How can I compare the latest states/heads on Github?
https://github.com/github/linguist/compare/master...gjtorikian:master
github:master is up to date with all commits from gjtorikian:master.
Try switching the base for your comparison.
It means that all commits from gjtorikian/liguist are part of github/linguist.
The reverse is not true:
https://github.com/gjtorikian/linguist/compare/master...github:master
That would give all (1866) commits from github/linguist which are not part of gjtorikian/linkguist.
This is triple-dot '...' diff between the common ancestor of two branches and the second branch (see "What are the differences between double-dot “..” and triple-dot “…” in Git diff commit ranges?"):
In the first case github/linguist:master...gjtorikian/linguist:master, the common ancestor and gjtorikian/linguist:master are the same! O commits.
In the second case gjtorikian/linguist:master...github/linguist:master, github/linguist:master has 1866 commits since the common ancestor (here, since gjtorikian/linguist:master).
As a side note, the compare of forks can be reached from the compare page.
Say your project is Zipios:
https://github.com/Zipios/Zipios
What you want to do is add the .../compare to that URL:
https://github.com/Zipios/Zipios/compare
On that page, you can select two branches but if you look closely, at the top there is a link that says: compare across forks.
Once you clicked on that link, it shows you two extra dropdowns with your main branch and the list of forks.
What I have yet to discover is how to go from the main page of a project to the Compare page. Maybe someone could shed light on that part?
From #somerandomdev49:
To go to the compare page, go to the "Pull Requests" tab and click the "Create Pull Request" button.
If i got a task (ie HT-4949311) and i
fix the bug
and change the javadoc
... in the same File.
And i like to seperate these two changes by two different comments:
"HT-4949311: bugfix."
"HT-4949311: javadoc."
... i need to:
revert the javadoc-change,
commit the bugfix,
write the javadoc-change again,
commit the javadoc-change.
Is there a better way to do so?
Or is there any feature that lets me simple commit the selected lines only?
I'm not particularly experienced with ClearCase, so if my terminology is incorrect please let me know.
In Git I can run the command:
git archive -o /tmp/dump.zip $SHA_FROM_THE_PAST path/to/dump
I want to do something similar in ClearCase.
The ClearCase repository contains two branches: main and snapshot_foo.
snapshot_foo branches from main at some point in the past.
What I want is a dump of all the files as they looked at the time the snapshot was first created.
I understand that there is no 'global' state identifier like there is in Git; in AFAIK, in ClearCase each element is versioned individually, so there will not necessarily be a one-to-one equivalent to that command.
I've thought about creating a new snapshot starting at the same point in time from main, and just copying what I need from that, but I am bewildered and confused as to how I would go about it.
The simplest case would be when you have set a label on main just before creating snapshot.
But if you have no such label, you can get all the files at the time just before the creation of the snapshot_foo branch:
a/ cleartool descr -l brtype:snapshot_foo#/myVob to get the date of creation for this branch
b/ make a snapshot view with a time-based selection rule similar to this question
element /myPath/... /main/{!created_since(01-Sep-2008.12:34:56)}
element /myPath/... /main/LATEST
(with 12h 34 minutes 56 seconds being the time just before the creation of the brtype snapshot_foo)
(see the config_spec man page)
Once the snapshot view is created with the right versions in it, you can zip its content, achieving a similar result to the git archive you mention in your question.