Stephen J. Turnbull wrote:
Thomas> Arch is also still relevant compared to git because of
Thomas> integrity issues.
By which you mean?
Git picks a particular crypto hash and then pins all integrity on that.
That's too weak.
It'd take quite a few pages (forgive me for sparing myse
> "Thomas" == Thomas Lord <[EMAIL PROTECTED]> writes:
Thomas> I think you are close to right on a few things but not
Thomas> quite right overall.
I don't see anything that suggests I didn't hit it on the button. I
didn't say you didn't understand git, simply that arch isn't git and
i
Stephen J. Turnbull wrote:
> []
I think you are close to right on a few things but not quite right overall.
Git is very fast at many operations partly because its storage management
is "snapshot oriented": there is no need to compute a tree-delta at commit
time.
Git is also very fast becaus
> "Thomas" == Thomas Lord <[EMAIL PROTECTED]> writes:
Thomas> It seems to me that what you are really saying is that
Thomas> performance was, in general, a barrier to adoption.
Definitely.
Thomas> Performance of what operations, though? For example, my
Thomas> non-scientific
Aldrik KLEBER wrote:
Surely, Arch 2.0 is a new product. A new structure, new way of working, and
not only some optimizations, but a designing work, to make a new product that
better handle a problem for example.
For me optimization is a change on something existing yet.
I agree.
-t
__
Le Jeudi 20 Avril 2006 19:58, Thomas Lord a écrit :
> Aldrik KLEBER wrote:
> > What you call a bit of optimization is a new archive format, a new
> > working tree management, your optimizations describe a new product. IMHO
>
> Arch 2.0?
Surely, Arch 2.0 is a new product. A new structure, new way o
Aldrik KLEBER wrote:
What you call a bit of optimization is a new archive format, a new working
tree management, your optimizations describe a new product. IMHO
Arch 2.0?
-t
___
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu
That is a much more reasonable message because you dropped
the "shoot the messenger" crap and because you are no longer
asserting that "doing any useful work requires downloading all
of history." So, thanks for that.
It seems to me that what you are really saying is that performance
was, in gen
Le Jeudi 20 Avril 2006 19:11, Stefan Monnier a écrit :
> AFAICT, the patchlogs (in Arch) don't need pruning; they just need a bit of
> optimization:
>
> - drop the log comments, the dates, ... (tla can fetch them from the
> archive if needed; I don't know of any case where the speed to get them is
> 7. Automatically prune all patchlogs that have been around for more than
> 50 revisions. That should be enough to find good ancestors for merges
> and such. Perhaps a tunable variable on a branch per branch basis
> would make sense.
AFAICT, the patchlogs (in Arch) don't need pruning
> "John" == John Arbash Meinel <[EMAIL PROTECTED]> writes:
John> Jeremy Shaw wrote:
>> darcs get has a --partial flag:
John> Can it annotate files if you have a --partial? And how well
John> does it handle merging under those conditions?
"No", and "very likely barfs". All a
Le Jeudi 20 Avril 2006 11:56, James Blackwell a écrit :
> Thanks for the reply! I always look forward to your pearls of wisdom. =)
>
> I'll stick to the technical aspects of your post. I don't feel comfortable
> commenting upon my previous employer. I recommend that you contact them
> directly if y
Thanks for the reply! I always look forward to your pearls of wisdom. =)
I'll stick to the technical aspects of your post. I don't feel comfortable
commenting upon my previous employer. I recommend that you contact them
directly if you have any questions. More clearly: I'm not part
of "you folks a
James Blackwell wrote:
I'm sure that you're happy to shoot this particular messenger whenever the
opportunity presents itself.
Let's retrace here and examine just what you're doing with
posts like this.
You earlier wrote:
James> The hindrance is that all of the drcs's that I can think
James> o
Jeremy Shaw wrote:
> At Wed, 19 Apr 2006 18:31:25 -0400,
> James Blackwell wrote:
>
>> Whats needed in this field is research on how to minimise the requirement
>> for history and then to delay downloading it until its necessary. There's
>> some anecdotal proof in the arch world that one can delay
I'm sure that you're happy to shoot this particular messenger whenever the
opportunity presents itself. I can even understand why -- I used to work
at a company that you wrongly believe destroyed you. But lets leave that
off to the side. Fighting on a mailing list is like participating in the
spec
At Wed, 19 Apr 2006 18:31:25 -0400,
James Blackwell wrote:
> Whats needed in this field is research on how to minimise the requirement
> for history and then to delay downloading it until its necessary. There's
> some anecdotal proof in the arch world that one can delay getting
> information in an
James Blackwell wrote:
The hindrance is that all of the drcs's that I can think of today all have
one requirement that devastates DRCS usage in projects with reasonably
sized histories -- doing any useful work involves downloading all
history.
I do intend to reply to Ludovic separately but I
On Wed, Apr 19, 2006 at 02:13:09PM +0200, Ludovic Courtès wrote:
> Hi,
>
> Thomas Lord <[EMAIL PROTECTED]> writes:
>
> > Aside from SoC, it might be interesting to think out loud a bit about
> > the status
> > of 2.0, though. Hmm
>
> I'd be interested in hearing what we would expect from an
Hi,
Thomas Lord <[EMAIL PROTECTED]> writes:
> Aside from SoC, it might be interesting to think out loud a bit about
> the status
> of 2.0, though. Hmm
I'd be interested in hearing what we would expect from an Arch 2.0.
I've somewhat given up following the evolution of Free Software DRCS.
M
Andy Tai wrote:
Hi, I am thinking maybe this is a resource useful for Arch. We can
participate in the Google Summer of Code to recruit some students to
help push Arch forward... One thing is a project to port more of the
Arch 1 functionality to Arch 2.0. Would this be a good thing to do?
To
21 matches
Mail list logo
