What is the difference between ColladaLoader.js and ColladaLoader2.js given by Mr.Doob in examples/ folder of GitHub?
Does one have an advantage over the other?
I suppose you are referring to mrdoob three.js JavaScript 3D library.
Its examples/js/loaders folder do include a ColladaLoader.js and a ColladaLoader2.js file.
Note that there was an issue with the first one (see issue 7388): use the one from the dev branch: dev/examples/js/loaders/ColladaLoader.js
As mentioned in issue 7256:
the current ColladaLoader is out of control.
I've started a new ColladaLoader2 from scratch in the dev branch.
So the 2 is a re-implementation of the first one.
Related
I want to display some lines of code on my website (created with GithubPages and Jekyll), extracted from a commit of my repository.
Example :
for some lines
https://github.com/fredericletellier/udacity-builditbigger/blob/6fe561a9e514de2e7175e2c16c5b3a1280223d2e/jokelib/src/main/java/com/joke/JokeProvider.java#L15-L22
for a diff of a specific file in a commit
https://github.com/fredericletellier/udacity-builditbigger/commit/6fe561a9e514de2e7175e2c16c5b3a1280223d2e?diff=unified#diff-6359bfff8a23dfc88d092acc996f6f97
But i need to quote a lot of code, and it is very long to copy-paste my code on gist. For the moment, i can provide a link to the interesting code.
Can i find a simple way to display this code in a snippet ?
UPDATE
If you have an another answer, you are welcome !
I found an answer : https://gist-it.appspot.com/
The first example, file on the latest version on a branch, should not be use.
When the code was changed, the snippet display something wrong. Prefer use the permalink to a file in a specific commit like in the second example : https://help.github.com/articles/getting-permanent-links-to-files/
The second example, a file or a part of a file in a specific version/commit :
<script src="http://gist-it.appspot.com/https://github.com/fredericletellier/udacity-builditbigger/blob/6fe561a9e514de2e7175e2c16c5b3a1280223d2e/jokelib/src/main/java/com/joke/JokeProvider.java?slice=14:22&footer=0"> </script>
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.
I have a large amount of code that I'm running doxygen against. To improve performance I'm trying to break it into modules and merge the result into one set of docs. I thought tag files would do the trick, but either I have it configured wrong or I'm misunderstanding how it works.
The directories are laid out:
root +
|-src+
| |-a
|
|-doc+
|-a.dox
|-main.dox
|-main.md
|-output+
|-a+
| |-html
|-main+
|-html
In addition to 'a' there are other peer directories but am starting with one.
a.dox generates output and a tag file into root/doc/output
OUTPUT_DIRECTORY=output/a
GENERATE_TAGFILE = output/a/a.tag
INPUT=../src/a
main.dox just inputs the markdown file that has a mainpage tag and refers to the other projects tag file.
OUTPUT_DIRECTORY=output/main
INPUT = main.md
TAGFILES=output/a/a.tag=output/a/html
Should this merge or link all the docs under main where I can browse 'a' globals, modules, pages, etc? Or does this only generate links to 'a' if I explicitly cross-reference a documented entity in 'a' from inside of 'main'?
If this should work, any thoughts on where my syntax is incorrect? I've tried various ways to define TAGFILES, is the output directory relative to the main.dox file? To the a.tag file? Or to the a/html directory?
If I'm off base an TAGFILES don't work this way, is there another way to merge sets of doxygen directories into one?
Thanks.
I suggest you read this topic on how I recommend to use tag files and the conditions that should apply: https://stackoverflow.com/a/8247993/784672
To answer your first question: doxygen will in general not merge the various index files together (then no performance would be gained). Although for a part you can still get external members in the index by setting ALLEXTERNALS to YES.
Doxygen will (auto)link symbols from other sources imported via a tag file. So in general you should divide your code into more or less self-contained modules/components/libraries, and if one such module depends on another, then import its tag file so that doxygen can link to the other documentation set. If you run doxygen twice (once for the tag file and once for the documentation) you can also resolve cyclic dependencies if you have them.
In my case I made a custom index page with links to all modules, and made a custom entry in the menu of each generated page that linked back to this index (see http://www.doxygen.nl/manual/customize.html#layout) how to add a user defined entry to the navigation menu/tree.
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.
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/