I think the main advantage of a DVCS is that it allows many many
people to make changes to a project and to integrate those changes in
a non-insane way. Given that R as a very restricted list of people who
actually make changes to the source, it doesn't seem that something
like git or Hg would prov
> In mercurial (Hg) a particular snapshot can be labeled with a tag, and
> then referred to by that name in the future.
Bazaar can tag revisions as well: http://wiki.bazaar.canonical.com/Tag
Git too: http://www.kernel.org/pub/software/scm/git/docs/git-tag.html
Sincerely
Sveinung Kvilhaugsvik
One small technical note:
Simon said
> That (non-linear history) is IMHO the biggest drawback of DVCS because
> that means there is no way to link a particular build to the source
> status and you cannot use globally valid build numbers.
In mercurial (Hg) a particular snapshot can be labeled with
On Wednesday, May 26, 2010, Peter Dalgaard wrote:
> Antonio, Fabio Di Narzo wrote:
>
>> Beside, people working simultaneously on the same files and needing
>> svn to tell them of that? And that happening often? I would hope on
>> better human interaction and work division, rather than svn conflict
Antonio, Fabio Di Narzo wrote:
> Beside, people working simultaneously on the same files and needing
> svn to tell them of that? And that happening often? I would hope on
> better human interaction and work division, rather than svn conflicts
> checks. But...
>> [Note: again, this is rather about
2010/5/26 Simon Urbanek :
>
> On May 26, 2010, at 12:26 PM, Antonio, Fabio Di Narzo wrote:
>
>> 2010/5/26 Hadley Wickham :
> Yes, that's a very good point (although in my experience it takes a
> very long time to do the initial download of the SVN repository). I'm
> not an expert on the
On 5/26/10 4:16 AM, Gabor Grothendieck wrote:
Note that one can also use any of the dvcs systems without actually
moving from svn by using the dvcs (or associated extension/addon) as
an svn client or by using it on an svn checkout.
FWIW, I have been using git for several years now as my vsc of
On May 26, 2010, at 12:26 PM, Antonio, Fabio Di Narzo wrote:
> 2010/5/26 Hadley Wickham :
Yes, that's a very good point (although in my experience it takes a
very long time to do the initial download of the SVN repository). I'm
not an expert on these systems, but I imagine the main
On Wed, May 26, 2010 at 11:38 AM, Hadley Wickham wrote:
> It's a real
> shame that this unique component of R-forge is so closely connected to
> the tools that many other sites provide.
R-Forge does have the capability of mirroring an external subversion
repository according to section 4.2 of the
On May 26, 2010, at 11:35 AM, Hadley Wickham wrote:
>>> Yes, that's a very good point (although in my experience it takes a
>>> very long time to do the initial download of the SVN repository). I'm
>>> not an expert on these systems, but I imagine the main downside (other
>>> than speed) of havin
2010/5/26 Hadley Wickham :
>>> Yes, that's a very good point (although in my experience it takes a
>>> very long time to do the initial download of the SVN repository). I'm
>>> not an expert on these systems, but I imagine the main downside (other
>>> than speed) of having SVN upstream is that you
> and .. for R-forge, e.g., which of these provide nice and
> flexible tools (as svn does) for an automatic web interface to
> inspect file histories, differences, etc.
Every svn alternative provides tools that are as good as or better
than R-forge, with the exception of package building. It's a
>> Yes, that's a very good point (although in my experience it takes a
>> very long time to do the initial download of the SVN repository). I'm
>> not an expert on these systems, but I imagine the main downside (other
>> than speed) of having SVN upstream is that you have to keep the
>> history lin
On May 26, 2010, at 10:01 AM, Felix Andrews wrote:
> I'm not necessarily advocating a migration; probably an administrative
> nightmare, and everyone involved would be forced to learn new stuff...
> I was just enthusing because I recently started using a DVCS for the
> first time.
>
>
> On 26 M
I'm not necessarily advocating a migration; probably an administrative
nightmare, and everyone involved would be forced to learn new stuff...
I was just enthusing because I recently started using a DVCS for the
first time.
On 26 May 2010 21:16, Gabor Grothendieck wrote:
> Note that one can also
Note that one can also use any of the dvcs systems without actually
moving from svn by using the dvcs (or associated extension/addon) as
an svn client or by using it on an svn checkout.
On Wed, May 26, 2010 at 5:44 AM, Martin Maechler
wrote:
>> Felix Andrews
>> on Wed, 26 May 2010 11
> Felix Andrews
> on Wed, 26 May 2010 11:20:12 +1000 writes:
> On second thoughts it is really none of my business how the R sources
> are managed.
> But I would encourage package developers and/or r-forge maintainers to
> consider these systems.
Thank you, Felix, for
On second thoughts it is really none of my business how the R sources
are managed.
But I would encourage package developers and/or r-forge maintainers to
consider these systems.
Regards
-Felix
On 26 May 2010 10:29, Felix Andrews wrote:
> Hi,
>
> Just wondering whether anyone had thought about mov
Hi,
Just wondering whether anyone had thought about moving the R sources
to a "distributed" version control system such as Bazaar, Git or
Mercurial. These new generation systems make it easier to work on
feature branches, allow working offline, are very fast, etc.
Some projects that have moved to
19 matches
Mail list logo
