yea - i figured nothing such is used, but it made sense to mention it
just in case...
For the record, it's valid for dojo to include $rev$ in their source files
in that way - makes reporting bugs or knowing what you have easier,
you just type
dojo.version and see 1.3.2 (18832) major=1 minor=3 patc
+1 (non-binding)
;-)
On Mon, Oct 19, 2009 at 6:32 PM, Christian Edward Gruber <
christianedwardgru...@gmail.com> wrote:
> I love blame (annotation).
>
> Christian.
>
>
--
Daniel Gredler
http://daniel.gredler.net/
I love blame (annotation).
Christian.
On Oct 19, 2009, at 6:30 PM, Howard Lewis Ship wrote:
Nope; we've even gotten away from use @author tags, never mide tags
with $Rev$, etc. You want to know the revision? Ask the SCM. The
author? Ask the SCM.
On Mon, Oct 19, 2009 at 1:50 PM, Andreas And
Nope; we've even gotten away from use @author tags, never mide tags
with $Rev$, etc. You want to know the revision? Ask the SCM. The
author? Ask the SCM.
On Mon, Oct 19, 2009 at 1:50 PM, Andreas Andreou wrote:
> btw, is there any part of T5 that uses keyword substitution such as $Rev$ ?
>
> I
btw, is there any part of T5 that uses keyword substitution such as $Rev$ ?
I just came across a gotcha in T4's dojo which uses that keyword in one of
the source files and parses the (numeric) substituted value in order
to know (and report)
its internal version... but it turns out git doesn't use
I took the matter of git up as an officially supported SCM on the
infra-dev list. It looks like the thread is going to die with no
reasonable resolution. I've been trying to address the issue both
from a technical and productivity standpoint. If you have any
feelings on the matter, please feel
and when (and if) tapestry will move to git I'll move and continue
development of
http://tapestry-jfly.sourceforge.net/ (the T5 dojo integration)
to tapestry360
kiuma
On Mon, Oct 5, 2009 at 8:30 AM, Howard Lewis Ship wrote:
> What's neat about Git is that it's core concept (multiple repositorie
What's neat about Git is that it's core concept (multiple repositories
that can be synced to each other) lends itself to any kind of workflow
you want, merely by applying a semantic meaning to particular
repositories ... much like the way you can pipe data across multiple
commands in a Unix shell.
Last friday I attended a talk on git and was fascinated. Git seems to be the
only the only proper model for open source since applying patches, merging
etc. is very easy. But I have similar concerns as Andy has.
It seems like Linus Torwalds has a small group of developers he trusts. He
pulls from
I don't think the concept of committers really changes.
I would say that we would restrict write access on GitHub to just
committers. Sure, anyone can clone the repository, and anyone can
request us to pull their changes ... but that's no different than
providing a patch via JIRA. It is possible
It's way too late over here + i don't consider myself an expert in git
(just a regualar user),
but i'll just try to express some initial thoughts:
- git is great, Tapestry (and i guess every other project) has a lot
to gain from
moving to it...
- it's not yet clear to me what the overall apache fou
Hi Olivier,
While your concerns are well-founded, I don't think there's much to
worry about. The git tooling isn't up to speed as SVN, but SVN wasn't
up to speed with CVS at one point, either. The 1.0 release in
software is such a trite concept now that it's downright frustrating
people don't ju
Hi Howard and everything else with Git experience,
i'm not a commiter so my opinion does not really matter - but anyway:
>From my reading about Git on the web my impression is that Git
is not up to the level of tooling as SVN is.
If you are using Git from the commandline on linux I do not think
Hi Piero,
Please see comments in-line.
On Sun, Oct 4, 2009 at 5:55 AM, Piero Sartini wrote:
>> So here's a question ... what's preventing us from moving the Tapestry
>> code base to GitHub?
>
> Did you take a look at Mercurial? Personally I would prefer it over git, but
> that's a matter of tast
I'm a fan of moving to git. I've gotten so accustomed to a git
workflow now that using SVN feels like a major step back. In the
meanwhile, I've been using git-svn against svn.eu.apache.org.
Unfortunately, that approach is just way too frustrating because of
the EU mirror sync lag time with the of
> So here's a question ... what's preventing us from moving the Tapestry
> code base to GitHub?
Did you take a look at Mercurial? Personally I would prefer it over git, but
that's a matter of taste. I am no committer or contributor so my preference is
not really important for tapestry developmen
So here's a question ... what's preventing us from moving the Tapestry
code base to GitHub?
I've been using Git and GitHub increasingly for the last several
months; I'm running client projects off of a private repo at GitHub.
My whole approach has shifted around Git's capabilities, including
tiny
17 matches
Mail list logo