On Mon, 2005-02-21 at 20:45, [EMAIL PROTECTED] wrote:
> CVS was pretty good at keeping files sane, but I'll go for a solution that
> completely sidesteps said problem any day.
One way to get the benefits of both worlds would be to keep an
additional history of changes (in whatever form) that allow
On Mon, 21 Feb 2005, David Roundy wrote:
I just scanned the comparison of various source-code management
schemes at
http://zooko.com/revision_control_quick_ref.html
and found myself wishing for a similar review of bk (which was
excluded, not being open-source).
Would you (or anyone else) be
[EMAIL PROTECTED] said:
> On Mon, Feb 21, 2005 at 04:53:06PM +0100, Andrea Arcangeli wrote:
[...]
> > AFIK all other SCM except arch and darcs always modify the repo, I never
> > heard complains about it, as long as incremental backups are possible
> > and they definitely are possible.
> Well, a
On Mon, Feb 21, 2005 at 04:53:06PM +0100, Andrea Arcangeli wrote:
> Hello Miles,
>
> On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote:
> > Yeah, the basic way arch organizes its repository seems _far_ more sane
> > than the crazy way CVS (or BK) does, for a variety of reasons[*]. No
>
On Mon, Feb 21, 2005 at 07:41:54AM -0500, David Roundy wrote:
> The catch is that then we'd have to implement a smart server to keep users
> from having to download the entire history with each update. That's not a
> fundamentally hard issue, but it would definitely degrade darcs' ease of
> use,
Hello Miles,
On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote:
> Yeah, the basic way arch organizes its repository seems _far_ more sane
> than the crazy way CVS (or BK) does, for a variety of reasons[*]. No
> doubt there are certain usage patterns which stress it, but I think it
> mak
On Saturday 19 February 2005 12:53 pm, Andrea Arcangeli wrote:
> Wouldn't using the CVS format help an order of magnitude here? With
> CVS/SCCS format you can extract all the patchsets that affected a single
> file in a extremely efficient manner, memory utilization will be
> extremely low too (lik
On Sat, Feb 19, 2005 at 06:53:48PM +0100, Andrea Arcangeli wrote:
> On Sat, Feb 19, 2005 at 12:15:02PM -0500, David Roundy wrote:
> > The linux-2.5 tree right now (I'm re-doing the conversion, and am up to
> > October of last year, so far) is at 141M, if you don't count the pristine
> > cache or wo
Dustin Sallings writes:
> but the nicest thing about arch is that a given commit is immutable.
> There are no tools to modify it. This is also why the crypto
> signature stuff was so easy to fit in.
>
> RCS and SCCS storage throws away most of those features.
Yeah, the basic way arch organizes i
Hi,
David Roundy, creator of darcs, wrote:
> On Sat, Feb 19, 2005 at 05:42:13PM +0100, Andrea Arcangeli wrote:
> > I read in the webpage of the darcs kernel repository that they had
> > to add RAM serveral times to avoid running out of memory. They
> > needed more than 1G IIRC, and that was enoug
On Sat, Feb 19, 2005 at 12:15:02PM -0500, David Roundy wrote:
> The linux-2.5 tree right now (I'm re-doing the conversion, and am up to
> October of last year, so far) is at 141M, if you don't count the pristine
> cache or working directory. That's already compressed, so you don't get
> any extra
On Sat, Feb 19, 2005 at 05:42:13PM +0100, Andrea Arcangeli wrote:
> But anyway the only thing I care about is that you import all dozen
> thousands changesets of the 2.5 kernel into it, and you show it's
> manageable with <1G of ram and that the backup size is not very far from
> the 75M of CVS.
T
On Sat, Feb 19, 2005 at 04:10:18AM -0500, Patrick McFarland wrote:
> In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. By
> using it's super magical method, it represents how code is written and how it
> changes (patch theory at its best). You can clearly see the direction
On Sat, February 19, 2005 4:10 am, Patrick McFarland said:
> On Friday 18 February 2005 07:50 am, Andrea Arcangeli wrote:
>> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
>> > RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
>>
>> The advantage it will provide i
On Friday 18 February 2005 07:50 am, Andrea Arcangeli wrote:
> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
> > RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
>
> The advantage it will provide is that it'll be compact and a backup will
> compress at best too.
On Feb 18, 2005, at 1:09, Andrea Arcangeli wrote:
darcs scares me a bit because it's in haskell, I don't believe very
much
in functional languages for compute intensive stuff, ram utilization
It doesn't sound like you've programmed in functional languages all
that much. While I don't have any p
On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
> RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
The advantage it will provide is that it'll be compact and a backup will
compress at best too. Small compressed tarballs compress very badly
instead, it wouldn't be
On Fri, 18 Feb 2005 10:09:00 +0100, Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:
> > small to medium sized ones). Last I checked, Arch was still too slow in
> > some areas, though that might have changed in recent months. Also, many
>
On Fri, Feb 18, 2005 at 10:09:00AM +0100, Andrea Arcangeli wrote:
> darcs scares me a bit because it's in haskell, I don't believe very much
> in functional languages for compute intensive stuff, ram utilization
> skyrockets sometime (I wouldn't like to need >1G of ram to manage the
> tree).
AFAIC
On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:
> small to medium sized ones). Last I checked, Arch was still too slow in
> some areas, though that might have changed in recent months. Also, many
IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the
backend and
On Thu, February 17, 2005 9:24 pm, Tupshin Harper said:
Hi Tupshin,
> Speaking as somebody that uses Darcs evey day, my opinion is that the
> future of OSS SCM will be something like arch or darcs but that neither
> are ready for projects the size of the linux kernel yet. Darcs is
> definitely wa
Patrick McFarland wrote:
On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote:
Something that unintentionally started a flamewar.
Well, we just went through another round of 'BK sucks' and 'BK sucks, we need
to switch to something else'.
Sans the flamewar, are there any options? CVS and
22 matches
Mail list logo
