Forums : Technical Issue Help
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.synopsys.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
Mismatch in number of commits
Hello!
The summary for this project says the the all time
commit count is 1088:
https://www.ohloh.net/p/tendra/commits/summary
The repository actually has about 2900 commits. Confusingly I can see the most recent commit messages in the log on that page.
What's going on here? Does the all time
commit field need updating somehow?
Thank you!
Kate,
It looks as if the current repository trunk starts at r1797 Centralise tags for #248 restructure.
The count of commits is cumulative and doesn't relate to the revision numbers particularly. See: https://www.ohloh.net/p/tendra/commits/245225593 This is the earliest revision we were able to retrieve. If older history exists somewhere in the branches or tags, you could add it as a separate enlistment at the possible expense of accurate lines-of-code counts where the source code might be duplicated between the different enlistments.
Let me know if you have any additional questions or if I can lend a hand.
Thanks!
Ah. So what is now the trunk didn't used to be, originally; the repository was laid out differently.
I know your note for subversion code locations suggests to add /trunk rather than /, but in this case should I remove the /trunk source and add / instead?
Then I can add rules to your edit ignored files
to ignore /tags and /branches. Does that sound reasonable?
Kate,
As with most things, the answer is it depends...
If the contents of the whole subversion isn't too huge, you can do just as you suggest. The problem is, we won't process the ignore order until after the whole shebang is brought down and analyzed the first time. The size of /trunk is 107 mb. If everything taken together is 1 Gb plus-or-minus, we could probably handle that though it will take a while to chew through. Then once the ignore order is in-place, the updates will be more modest. The original caveat is that if source code is repeated in the various branches etc. that will distort the lines-of-code counts and all the other metrics that depend on that information. You may want to consider two ohloh projects: one that represents the project as it is today and another project that includes all the appropriate branches and would be a historical
project that honors all the hard work of all the contributors through the present. The first project would provide up-to-date accurate information that you could use for promotional purposes via our widgets etc. while the second project would be more general-purpose. I've suggested this to many managers in the past though I'm not sure how satisfactory that compromise is.
Let me know if any other questions come up.
Thanks!
It's not that big. Thank you!
Hi again. I'd like to reopen this issue as a feature request.
The above is all true. I just wanted to add a note: the problem here seems to be that ohloh's code analysis does the equivalent to this:
iona% svn ls -r1700 svn://svn.tendra.org/tendra
svn: E195012: Unable to find repository location for 'svn://svn.tendra.org/trunk' in revision 1700
whereas I think it should be using a peg
revision, instead:
iona% svn ls svn://svn.tendra.org/tendra@1700
branches/
tags/
trunk/
(1700 is a revision from before / was moved)
...so all this information is there for the grabbing. Ohloh just doesn't grab it. But it could, if that ability were to be added. So that's my feature request: use peg revisions instead of -r revisions.
Thanks,
Kate,
An interesting suggestion. I'll pass it on to management and see if it gets any traction.
Thanks!