[darcs-users] some darcs comments from Johan Tibell
johan.tibell at gmail.com
Sat Jan 2 14:57:53 UTC 2010
On Mon, Dec 28, 2009 at 7:29 PM, Eric Kow <kowey at darcs.net> wrote:
> On Sun, Dec 27, 2009 at 14:16:07 +0100, Johan Tibell wrote:
> For small projects, I tend to have a single directory in which I dump
> all my repositories:
> But for larger projects, I tend to have a single directory just for that
> (so cd darcs-hacking; darcs get --lazy http://darcs.net review-291)
Makes sense. I now use the first approach for the "network" library.
> My main worry (personally) is losing the simplicity of Darcs, which I
> think is a quality that we should hang to very tenaciously.
Simplicity is a good principle, and I think it's one worth sticking
too. However, sometimes you need to do complicated things (e.g. whole
tree reorganisation) to your repository. I prefer to have those
operations available, even though tricky to use, than not at all.
There's nothing more frustrating than being in a situation where you
really need to do something (e.g. recover from some problem) and your
SCM not allowing you to. Some of the power of Git is that it makes
some of these difficult but sometime necessary operations possible.
> I just had a thought on one principle we could adopt that could help
> us preserve this simplicity. Johan: since you're an active user of
> branches, could you comment on the following idea?
> Darcs should never implement 'remote' branches.
> Branches should be strictly a personal affair, something a hacker would
> use to work on multiple features at the same time, or a maintainer to
> keep track of a bunch different patch sets; but NOT for a project that
> wants to publish multiple branches (they'd have to do it the old
> fashioned way).
> Perhaps this sort of simplifying principle will help. Basically the
> idea is that we should consider making a point of not EVER implementing
> (a) copying of branches and (b) pushing to and pulling from branches in
> other repos. That branches be tied to a single directory may allow us
> to make life more convenient for the most common use cases while keeping
> Darcs simple to use and think about.
I personally haven't used remote branches in Git so I'm not quite
qualified to comment. I would imagine talking to someone who maintains
a couple of version of e.g. the same library and ask him/her about the
pros/cons of being able to push many branches at once. Perhaps it's
valuable if you make a fix to e.g. the vXX branch and HEAD at the same
time and want to push both.
>> > fs runs Fedora Core 3 and has two SATA disks in a software RAID 1 array.
>> > I can only assume that when people complain about slow branch creation
>> > - they're *really* impatient;
>> > - they're using NFS on 100baseT (like me);
>> This is on local disk.
> Trent: any ideas on what's going on here? Is there some good
> reason for this sort of discrepancy if any?
>> > - they're not using --lazy for branches;
>> Aside: I want all my history locally so I don't use lazy.
> Even when branching an already local repo? What's there to lose?
I didn't really use local branches in Darcs but I imagine that --lazy
would be fine that although perhaps subsumed by hard linking. I find
that to be an optimization that the tool (i.e. Darcs) should worry
>> I remember back when that feature was announce and it didn't make any
>> sense to me back then. Would severely increase the variability in
>> execution times of different commands? There's lots of research
>> showing that high variability is even worse than consistently slow
>> operations when it comes to user perceived latency.
> I recommend just trying this to see how it feels. So I think what makes
> --lazy work well in practice is that in practice, one does not actually
> consult the patches that are far back in history very often.
I'll try it out.
> I think it would make sense to try it and see how it feels in practice,
> see what life is like with some lazy repos. If you're on a plane, you
> lose the ability to view the contents of a patch that you don't have,
> but is that really such a huge cost compared to the one you pay more
The cost of pulling a complete (Git) repository isn't really that high
given the efficiency of pack file transfer. Unexpected slowdowns are
much worse as they are just that, unexpected.
>> What about when I'm on a plane?
> Well you lose the ability to consult the patches that are far back in
> history... if you're on a plane.
I just want to clarify that I am indeed on a plane between our
California and Zurich office once in a while so this is not a
theoretical point I bring up to be annoying. :)
> I think it's a good goal for the future. For now, we're focused on
> fixing the more egregious issues like things taking many seconds or even
> minutes that should be faster. If we can knock a lot of these issues
> out (eg. implement filecache so that darcs annotate is usably fast,
> making darcs get fast over a network, making darcs not keel over and die
> if you try to record too large a patch), then we can start to worry
> about instantaneous operations.
Sounds like a good plan.
>> I use an external diff tool.
> To diff across branches in the current setup, you'd just use that
> external diff tool without any darcs commands.
> To diff across versions, there is now an --index=N-M flag... which
> unfortunately is broken at the moment
> But once that works again, I think it'd be the same feature.
Will this make me able to diff across branches and versions at the
same time? The external diff tool alone can't do that.
>> The hashes in Git are used everywhere so you're likely to have the
>> hash available (further up in your terminal screen) when you need it.
>> The same cannot be said about Darcs' hashes.
> So would a good default be for darcs changes to always print out the
> patch-info hash for each patch?
Yes, I think so.
Thanks for your comments/clarifications.
More information about the darcs-users