 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/28/2011 1:32, Orchid XP v8 wrote:
> http://koweycode.blogspot.com/2011/04/why-darcs-users-care-about-consistency.html
Thanks. That's interesting.
"""
The most well-known remaining cause of blowups in theory 2 is the problem of
"conflict fights" where one side of the conflict resolves the conflict and
gets on with their life without propagating the resolution back to the other
side.
"""
This is basically the source of the mess in git, also. In the whole blah
going on here: http://bramcohen.livejournal.com/74462.html I'm not sure I
can understand how presenting that work as a set of patches makes sense.
You'd wind up with a repository that changes A into B twice and B into A
once without any particular ordering between them, so I'm lost as to how
Darcs would handle that.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> http://koweycode.blogspot.com/2011/04/why-darcs-users-care-about-consistency.html
>
> Thanks. That's interesting.
Interesting, disturbing, whatever you want to call it. ;-)
All describing problems I've never come across. Then again, when your
development team consists of one person...
> """
> The most well-known remaining cause of blowups in theory 2 is the
> problem of "conflict fights" where one side of the conflict resolves the
> conflict and gets on with their life without propagating the resolution
> back to the other side.
> """
Given the entire purpose of *distributed* revision control... yeah, that
would be a problem. (Exponential-time merge worries me more though.)
> This is basically the source of the mess in git, also. In the whole blah
> going on here: http://bramcohen.livejournal.com/74462.html I'm not sure
> I can understand how presenting that work as a set of patches makes
> sense. You'd wind up with a repository that changes A into B twice and B
> into A once without any particular ordering between them, so I'm lost as
> to how Darcs would handle that.
You understand that Darcs *does* have an ordering between *related*
patches, right? It's only *unrelated* patches that have no order
relationship. I can flip the same line of code back and forth 20 times,
and record that as 20 patches, and they will have a strictly linear
ordering.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/29/2011 2:55, Orchid XP v8 wrote:
> You understand that Darcs *does* have an ordering between *related* patches,
Yes, I figured that.
Indeed, that's my main complaint with the whole concept: the idea that
simply because two patches are in different files doesn't mean they're
unrelated. If I implement foo() in file abc.c and call foo() in file def.c,
those are not two unrelated patches.
> right? It's only *unrelated* patches that have no order relationship. I can
> flip the same line of code back and forth 20 times, and record that as 20
> patches, and they will have a strictly linear ordering.
So, you clone a repository and I clone a repository.
You create a file called XX with the line Hello in it.
I create a file called XX with the line Goodbye in it.
We both record our changes.
I then change my XX file to say "Hello\nGoodbye".
You change your XX to say "Goodbye\nHello".
We both record our changes.
I then change my XX file to say "Hello". You change yours to say "Goodbye".
We both record our changes.
We attempt to merge our repositories.
Can you try this on a blank repository on your machine and tell me what happens?
Resolving this in git is very straightforward. You can just pick one that's
right and say "Henceforth, that's the answer". Or you can just grab all the
changes and basically never merge them back together again (say, if you have
two distros in the same repository).
Also, what happens if I rename a file from XXX to YYY and you rename it from
XXX to ZZZ? Do I wind up with both YYY and ZZZ in my repository?
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/29/2011 2:55, Orchid XP v8 wrote:
> You understand that Darcs *does* have an ordering between *related* patches,
> right? It's only *unrelated* patches that have no order relationship.
BTW, the problem here is that those patches are *not* related. Each branch
down the side is a separate Darcs repository. So the first guy takes A,
makes it a B, then patches it back to A. In parallel, in *your* repository,
you independently take A and make it into B. Now everyone copy all the
patches from everyone else. Do I wind up with A or B? I'm not sure there's
an answer there that makes sense from a technical perspective.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29/04/2011 05:16 PM, Darren New wrote:
> Indeed, that's my main complaint with the whole concept: the idea that
> simply because two patches are in different files doesn't mean they're
> unrelated. If I implement foo() in file abc.c and call foo() in file
> def.c, those are not two unrelated patches.
And my complaint about Git is that just because change X happened after
change Y does not necessarily mean that change X depends on change Y in
any way, yet Git assumes that it does.
Fundamentally, I expect working out which changes truly depend on each
other is probably undecidable. [And that's before we even get into the
fact that the only way for this to work properly is to implement a
seperate detection engine for every programming language you ever want
to version control.]
Apparently both models do work in practise, since there are people using
them. Personally, I much prefer the way Darcs does it.
> We both record our changes.
>
> We attempt to merge our repositories.
>
> Can you try this on a blank repository on your machine and tell me what
> happens?
I imagine Darcs will say "error, these changes conflict, please fix it".
And other words, "I can't figure out what to do; you decide".
> Resolving this in git is very straightforward. You can just pick one
> that's right and say "Henceforth, that's the answer". Or you can just
> grab all the changes and basically never merge them back together again
> (say, if you have two distros in the same repository).
That sounds in principle like the same thing that Darcs does.
> Also, what happens if I rename a file from XXX to YYY and you rename it
> from XXX to ZZZ? Do I wind up with both YYY and ZZZ in my repository?
Same again, I would imagine.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29/04/2011 05:18 PM, Darren New wrote:
> BTW, the problem here is that those patches are *not* related. Each
> branch down the side is a separate Darcs repository. So the first guy
> takes A, makes it a B, then patches it back to A. In parallel, in *your*
> repository, you independently take A and make it into B. Now everyone
> copy all the patches from everyone else. Do I wind up with A or B? I'm
> not sure there's an answer there that makes sense from a technical
> perspective.
I haven't tried it personally, but as I understand it, Darcs says "there
is a conflict here; please decide what you want me to do".
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/29/2011 9:55, Orchid XP v8 wrote:
> yet Git assumes that it does.
Yep. It's a question of whether you're being conservative or not, is all.
> Fundamentally, I expect working out which changes truly depend on each other
> is probably undecidable.
I don't think it's undecidable. I think it merely depends on what your specs
are.
Indeed, if I take a file that prints nothing and make it print "Hello", and
you take a file that prints nothing and make it print "Goodbye", then it's
obviously impossible to figure out in the merge which should come first and
which should come second, or if either at all is right.
> Apparently both models do work in practise, since there are people using
> them. Personally, I much prefer the way Darcs does it.
I can see the appeal of both. I wasn't really pushing for git as being
better. My original post was "hey, I found a good way to understand it."
> I imagine Darcs will say "error, these changes conflict, please fix it". And
> other words, "I can't figure out what to do; you decide".
But then how do you resolve it, such that I get the same resolution?
>> Resolving this in git is very straightforward. You can just pick one
>> that's right and say "Henceforth, that's the answer". Or you can just
>> grab all the changes and basically never merge them back together again
>> (say, if you have two distros in the same repository).
>
> That sounds in principle like the same thing that Darcs does.
I don't think Darcs lets me merge your patches back in and easily work on
one set or the other, right? Each repository really only holds one
authoritative version of the patches, right? I.e., there's exactly one
"pristine" that you compare against?
>> Also, what happens if I rename a file from XXX to YYY and you rename it
>> from XXX to ZZZ? Do I wind up with both YYY and ZZZ in my repository?
>
> Same again, I would imagine.
Yeah, OK.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/29/2011 10:18, Darren New wrote:
> On 4/29/2011 9:55, Orchid XP v8 wrote:
>> yet Git assumes that it does.
>
> Yep. It's a question of whether you're being conservative or not, is all.
Or, to be fair, more appropriately, git doesn't imply that just because
change A followed change B that change B depends on change A. Reading
dependencies into the order of commits is reading in something that isn't there.
Git is storing a series of snapshots. Each commit contains a complete record
of everything that was in your working directory when you committed it
(sorta, using Darcs terms). Each commit points to the version that was in
your working directory that you changed in order to get the new version. As
I said, git doesn't store changes. It says "he started with X, then he had
with Y," with no real implication that Y somehow depends on X.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 20 Apr 2011 16:49:57 +0100 in povray.off-topic, Invisible wrote:
> The problem Git seems to have is that it uses heads to keep track of
> things. Delete the head and the corresponding commit drops off the face
> of the Earth.
Actually, there are usually many ways to retrieve a lost head.
.git/logs/ directory is the most prominent tool or that.
The terminal's history buffer is another. Usually the very
commands that drop the current head will print its name.
--
Joel Yliluoma - http://iki.fi/bisqwit/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/27/2011 1:31, Joel Yliluoma wrote:
> On Wed, 20 Apr 2011 16:49:57 +0100 in povray.off-topic, Invisible wrote:
>> The problem Git seems to have is that it uses heads to keep track of
>> things. Delete the head and the corresponding commit drops off the face
>> of the Earth.
>
> Actually, there are usually many ways to retrieve a lost head.
> .git/logs/ directory is the most prominent tool or that.
Actually, there are "relog" or "rehead" files or something like that, which
are basically text files listing each head and the corresponding SHA1 as a
log file each time you move a head.
Also, doing the equivalent of a chkdsk will give you back any SHA1's that
don't have anything else pointing to them.
Both intentionally stick around for quite some time (several weeks by default).
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
