On 28/04/2011 03:21 PM, Chris Smith wrote:
On Thu, 2011-04-28 at 08:04 +0200, Bardur Arantsson wrote:
There's also the fact that using in-repo branches means that all the
tooling doesn't have to rely on any (fs-specific) conventions for
finding branches.
As someone who has admin'd a reasonably
On 04/28/2011 12:19 AM, Ganesh Sittampalam wrote:
On 26/04/2011 12:17, Malcolm Wallace wrote:
On 25 Apr 2011, at 11:13, Andrew Coppin wrote:
On 24/04/2011 06:33 PM, Jason Dagit wrote:
This is because of a deliberate choice that was made by David Roundy.
In darcs, you never have multiple
On Thu, 2011-04-28 at 08:04 +0200, Bardur Arantsson wrote:
There's also the fact that using in-repo branches means that all the
tooling doesn't have to rely on any (fs-specific) conventions for
finding branches.
As someone who has admin'd a reasonably large Bazaar setup (where
branch
==
On 2011-04-28 08:21 -0600, Chris Smith wrote:
It seems to me the same problems could be solved without the necessary
increase in complexity by:
(a) Keeping repositories in sibling directories with names.
(b) Keeping a working directory that you build in as one of these, and
switching it
Unfortunately, sharing a build directory between separate repositories
does not work. After a build from one repository, all the outputs from
that build will have modification times more recent than all the files
in the other repository.Then I suggest that your build tools are broken. Rebuilding
On 04/28/2011 05:23 PM, malcolm.wallace wrote:
Unfortunately, sharing a build directory between separate repositories
does not work. After a build from one repository, all the outputs from
that build will have modification times more recent than all the files
in the other repository.
Then I
On 2011-04-28 15:23 +, malcolm.wallace wrote:
Then I suggest that your build tools are broken. Rebuilding should
not depend on an _ordering_ between modification times of source and
object, merely on whether the timestamp of the source file is
different to its timestamp the last time we
There seems to be some misunderstanding here. I didn't suggest you share a
separate build directory between repositories... I suggested you have a
single repository that is the one you are currently building in, and that
you synchronize it with various other repositories as you swap branches.
On 26/04/2011 12:17, Malcolm Wallace wrote:
On 25 Apr 2011, at 11:13, Andrew Coppin wrote:
On 24/04/2011 06:33 PM, Jason Dagit wrote:
This is because of a deliberate choice that was made by David Roundy.
In darcs, you never have multiple branches within a single darcs
repository
On 25 Apr 2011, at 11:13, Andrew Coppin wrote:
On 24/04/2011 06:33 PM, Jason Dagit wrote:
This is because of a deliberate choice that was made by David Roundy.
In darcs, you never have multiple branches within a single darcs
repository directory tree.
Yes, this seems clear. I'm just
This is because of a deliberate choice that was made by David Roundy.
In darcs, you never have multiple branches within a single darcs
repository directory tree.
Yes, this seems clear. I'm just wondering whether or not it's the best design
choice.
It seems to me to be a considerable insight.
On 26 April 2011 13:16, Andrew Coppin andrewcop...@btinternet.com wrote:
2. I have no idea how to make Darcs do the thing with hard links (is that
even supported under Windows?) I just copy the whole folder using the normal
OS file tools.
darcs get path/to/other/local/repo
Either way, you
On Tue, Apr 26, 2011 at 6:35 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 26 April 2011 13:16, Andrew Coppin andrewcop...@btinternet.com wrote:
2. I have no idea how to make Darcs do the thing with hard links (is
that
even supported under Windows?) I just copy the whole
On Tuesday 26 April 2011 15:35:42, Ivan Lazar Miljenovic wrote:
How do you see how git branches are related to each other?
To some extent, you can see such a relation in gitk. For mercurial, hg glog
also shows a bit. I suppose there's also something to visualise branches in
bazaar, but I've
On 2011-04-26 15:51 +0200, Daniel Fischer wrote:
On Tuesday 26 April 2011 15:35:42, Ivan Lazar Miljenovic wrote:
How do you see how git branches are related to each other?
To some extent, you can see such a relation in gitk. For mercurial, hg glog
also shows a bit. I suppose there's also
On Tuesday 26 April 2011 16:04:55, Nick Bowler wrote:
On 2011-04-26 15:51 +0200, Daniel Fischer wrote:
On Tuesday 26 April 2011 15:35:42, Ivan Lazar Miljenovic wrote:
How do you see how git branches are related to each other?
To some extent, you can see such a relation in gitk. For
On Tue, Apr 26, 2011 at 3:16 PM, Andrew Coppin
andrewcop...@btinternet.com wrote:
Presumably David thought the same. I won't deny that there is a certain
simplifying elegance to it.
It does mean that you duplicate information. You have [nearly] the same
set of patches stored twice,
No, if
On Tue, 2011-04-26 at 16:34 +0200, Daniel Fischer wrote:
On Tuesday 26 April 2011 16:04:55, Nick Bowler wrote:
On 2011-04-26 15:51 +0200, Daniel Fischer wrote:
On Tuesday 26 April 2011 15:35:42, Ivan Lazar Miljenovic wrote:
How do you see how git branches are related to each other?
2. I have no idea how to make Darcs do the thing with hard links (is that
even supported under Windows?) I just copy the whole folder using the normal
OS file tools.
darcs get path/to/other/local/repo
Either way, you lose the ability to see how branches are related to each
other,
On 24/04/2011 06:33 PM, Jason Dagit wrote:
On Sun, Apr 24, 2011 at 2:05 AM, Andrew Coppin
andrewcop...@btinternet.com mailto:andrewcop...@btinternet.com wrote:
So I was a little surprised to discover that... Darcs doesn't
actually support doing this. Darcs is only really interested in
I've discovered something interesting.
Darcs stores history as a partially-ordered set of changes. This is a
beautiful and elegant idea. In theory, this lets me apply any
combination of changes, possibly generating file versions which have
never actually existed before. (E.g., the new type
On Sun, 24 Apr 2011, Andrew Coppin wrote:
(If you think about it, the difference between, say, GHC 7.0 and GHC 6.6 is
which set of changes are applied. Yet because Darcs doesn't support looking
at it like this, you must have a completely seperate repo for each one...)
But darcs shares the
On Sun, Apr 24, 2011 at 2:05 AM, Andrew Coppin
andrewcop...@btinternet.comwrote:
I've discovered something interesting.
Darcs stores history as a partially-ordered set of changes. This is a
beautiful and elegant idea. In theory, this lets me apply any combination of
changes, possibly
23 matches
Mail list logo
