RubyConf notes
Justin Love
base is (or was - haven't been through new ones much) rather full of
profanity.
RubyGems Gem::Command uses a class per command. They use
OptionParser, with options defined in the initialize method and 'def
execute' to define behavior.
Could we use the RDoc libs to put the command documentation inline?
Iterators: look into lazy enumerators, and implement #hash and #eql?
for anything that might be hashed.
Comparisons:
- Fog is an interface to different cloud hosts
- TicketMaster is an interface to different ticketing systems;
Lighthouse etc. Could also be an interesting extension.
Not sure if I posted about libgit2 (library focused C git
implementation) and it's Ruby wrapper, Ribbit See
https://github.com/technoweenie/git-nosql-talk
Grape is for defining APIs in Ruby. Could be interesting to apply to
the various server APIs.
--
Justin Love -- http://JustinLove.name/
http://ComputerGeneratedDreams.com/
"[T]he woods would be silent if no bird sang except the best."
- Henry Van Dyke
Ari Brown
On Nov 17, 2010, at 11:38 AM, Justin Love wrote:
> Dave Thomas called for less aggressive images and words; the Amp code
> base is (or was - haven't been through new ones much) rather full of
> profanity.
To this all I have to say is: lol.
> Could we use the RDoc libs to put the command documentation inline?
Does YARD not do the job? If not, then we can just run RDoc on the code and get what we want.
> Iterators: look into lazy enumerators, and implement #hash and #eql?
> for anything that might be hashed.
I was recently trying to turn the entire repository into a giant lazy enumerator, so I agree with this sentiment. That said, what do YOU mean by referring to lazy enumerators?
> Not sure if I posted about libgit2 (library focused C git
> implementation) and it's Ruby wrapper, Ribbit See
> https://github.com/technoweenie/git-nosql-talk
Cool! I didn't know about this.
- ari
Justin Love
>> Could we use the RDoc libs to put the command documentation inline?
> Does YARD not do the job? If not, then we can just run RDoc on the code and get what we want.
I was thinking pulling it at run time by having the command look up
it's own file, so that the command line docs and the offline docs
would be the same. Don't know if it's actually practical or not.
> I was recently trying to turn the entire repository into a giant lazy enumerator, so I agree with this sentiment. That said, what do YOU mean by referring to lazy enumerators?
This was all notes and ideas during RubyConf; I haven't checked to see
if the code already does that. I was thinking specifically of the new
1.9 Enumerators with a 'next' operation. I haven't looked up whether
it's different, or just done by using fibers over #each.
Ari Brown
On Nov 18, 2010, at 9:58 AM, Justin Love wrote:
> This was all notes and ideas during RubyConf; I haven't checked to see
> if the code already does that. I was thinking specifically of the new
> 1.9 Enumerators with a 'next' operation. I haven't looked up whether
> it's different, or just done by using fibers over #each.
Ah, generators. We use them in a few spots when needed, but currently the repository *itself* is not a generator. You're probably asking "Why would anybody care if the repository is generator", to which I'll just say my mind is weird.
Justin Love
> Ah, generators. We use them in a few spots when needed, but currently the repository *itself* is not a generator. You're probably asking "Why would anybody care if the repository is generator", to which I'll just say my mind is weird.
Yes, I forgot the proper term. Generating backwards in git (at least)
is probably a lot more efficient. I had a hack on the old repo to
enable rev numbers for the log/billing command, but it required
enumerating the entire history so you knew the proper number to assign
(and even then it was only valid for the current branch)
Michael Edgar
On Nov 18, 2010, at 12:48 PM, Justin Love wrote:
> On Thu, Nov 18, 2010 at 11:20, Ari Brown <a...@aribrown.com> wrote:
>> Ah, generators. We use them in a few spots when needed, but currently the repository *itself* is not a generator. You're probably asking "Why would anybody care if the repository is generator", to which I'll just say my mind is weird.
>
> Yes, I forgot the proper term. Generating backwards in git (at least)
> is probably a lot more efficient. I had a hack on the old repo to
> enable rev numbers for the log/billing command, but it required
> enumerating the entire history so you knew the proper number to assign
> (and even then it was only valid for the current branch)
This is something I've been wrapping around my head with git for about...
6 months now. It's the first example of where we need to be flexible to respect
different VCS philosophies, because git does not believe that revision numbers
are appropriate. I think there's a million mailing list requests asking for them,
and a million responses saying "no". You can hack it like Justin said by traversing
the history back to the root and then picking numbers, but they aren't canonical
in the way they are for hg/svn/cvs/etc.
So my vote is that repos can choose to either support integer indexing or not,
and any "standard library" functions should not rely upon revision numbers,
using only #parent(s) calls. That way, users can use an index from the command
line and have it understood by LocalRepository#[], but #unified_diff shouldn't
use revision numbers.
Thoughts, all?
Scott Chacon
On Thu, Nov 18, 2010 at 7:21 PM, Michael Edgar <ad...@carboni.ca> wrote:
>
> This is something I've been wrapping around my head with git for about...
> 6 months now. It's the first example of where we need to be flexible to respect
> different VCS philosophies, because git does not believe that revision numbers
> are appropriate. I think there's a million mailing list requests asking for them,
> and a million responses saying "no". You can hack it like Justin said by traversing
> the history back to the root and then picking numbers, but they aren't canonical
> in the way they are for hg/svn/cvs/etc.
Just to clarify, hg revision numbers are not canonical. They can be
and often are changed at will by Hg. If you and someone else clones a
repo and commit at the same time offline, you will both get say
revision '5' for your individual commits. If they push and you pull
and merge, you will still have revision '5' as your commit but their
revision '5' will be changed to '6' (and the merge commit will be
'7'). You can then push and when they pull, the revision they had
locally as '5' will now be renamed to '6'. In fact, if you merge in a
big branch of commits and push them, it can renumber big swaths of
changesets for anyone who then pulls and merges from you. The
revision number in Hg cannot be canonical because the system is
distributed. When Git people won't support this it is not because
they think it's funny but in fact because they don't want people to
depend in any way on a number that looks solid but can in fact be
changed at will.
If you want to emulate the hg functionality in git, just pick a tree
traversal technique and run it each time you need the numbers, which
is basically what hg is doing. or if you want to be faster about it,
just keep a hash table or array structure in a file in the .git
directory that maps commit SHAs to numbers as it sees them. The
former would make it so that everyone that had the same HEAD sha had
the same numbers all the time, but the latter would be faster.
Scott
Michael Edgar
I intuitively knew that hg numbers aren't canonical, but that's an awesome
explanation of why they really shouldn't be trusted as standard ever. I personally
think the git belief that they shouldn't be used to depend on them is good and valuable,
but in truth, I don't think people do often when it comes to Hg. I think people
mainly use them because it's easier than remembering the git shortcuts for
"3 commits ago". However, it's important to note it also lets you use numbers as
a shortcut for commits *not in the current branch*. If people communicate about
the project based on Hg revision numbers... well there's not much we can do to stop
them at this point.
That said, mercurial's file format means that it's *much* faster to get the set
of all commits in your repo and number them, because it's just an append-only
log of versioned data, including commits not in the current branch. Each file
(and a couple master logs) have this format, so when you run `hg log`, it literally
goes through the master log which has every commit it knows about, including other
branches. Git's tree structure means you have to scan every object in the system to
find all the commits, as far as I can tell. And that would be orders of magnitude slower.
Of course, that structure means other operations are faster for Git, but that's neither
here nor there.
So yeah, maintaining a cache of those could work... but I prefer instead that we
not provide a number-based revision interface for Git. It reflects our mission better
(trying to bring the VCSs together despite differences). We could eventually offer
it as a built-in extension, though, which would be nice for users of other systems
to get acclimated to Git.
Mike
Justin Love
> not provide a number-based revision interface for Git. It reflects our mission better
> (trying to bring the VCSs together despite differences). We could eventually offer
> it as a built-in extension, though, which would be nice for users of other systems
> to get acclimated to Git.
We might need multiple kinds of iterators - current branch, whole
repo, forward, backwards, etc. with a a few aliases, so that e.g. the
default current-branch iterator is backwards on git and forwards on
something else; if order matters use a more specific (but perhaps less
efficient) iterator.
Ari Brown
On Nov 18, 2010, at 2:21 PM, Michael Edgar wrote:
> This is something I've been wrapping around my head with git for about...
> 6 months now. It's the first example of where we need to be flexible to respect
> different VCS philosophies, because git does not believe that revision numbers
> are appropriate. I think there's a million mailing list requests asking for them,
> and a million responses saying "no". You can hack it like Justin said by traversing
> the history back to the root and then picking numbers, but they aren't canonical
> in the way they are for hg/svn/cvs/etc.
>
> So my vote is that repos can choose to either support integer indexing or not,
> and any "standard library" functions should not rely upon revision numbers,
> using only #parent(s) calls. That way, users can use an index from the command
> line and have it understood by LocalRepository#[], but #unified_diff shouldn't
> use revision numbers.
>
> Thoughts, all?
Just letting you know that I have some indecipherable grunts in my head about an idea for dealing with this. That is, I have an idea, but not really, and I can't really phrase it.