 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2011 4:21, Orchid XP v8 wrote:
>> "If the conflict is with one of your not-yet-published patches, you may
>> choose to amend that patch rather than creating a resolve patch."
>>
>> And that's exactly what the "git merge" command does.
>
> I thought "git merge" just combines changes, not resolves conflicts.
It doesn't. Altho there's the "git rerere" command, which resolves merge
conflicts the same way you did last time, if you want. :-)
What do you mean by "resolves conflicts"? That's a manual process in git and
in darcs.
> I wasn't even talking about conflicts. I'm talking about the fact that if
> the central repo changes, even in a way which does *not* conflict with your
> changes, you still have to update your local repo, remerge all the changes,
> and try again.
*If* you're *pushing* to a repository that is unattended, yes. How do you do
it in Darcs? What happens if people push conflicts into the central
repository? Is that where the "we ignore conflicts without telling you" part
comes in?
>> I'll grant you that Darcs is definitely simpler, but I think it's less
>> capable also, and that's the primary place the simplicity comes from.
>
> I disagree, but I don't think this argument is going anywhere productive
> right now.
It's less capable in that you only have one branch in a Darcs repository,
and you have no staging area where you can commit in sections. To the extent
that you avoid doing that in git, they seem pretty much identical to me.
> Yeah, it's only really useful for global names (e.g., functions or types).
Yeah, I try to avoid working in languages with global names. I honestly
don't really even know any languages like that any more. Even global names
in C aren't actually global.
> What should *really* happen is that Darcs looks at your edits and *detects*
> that it's a find-and-replace affecting only certain lines, and record that.
Yeah, when your repository system starts understanding that stuff, it has
some advantages. :-)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2011 10:38, Orchid XP v8 wrote:
>> But if they don't conflict, then that's one step. (Well, one step for
>> each of the 200 changes, just like in Darcs.)
>
> Except that you have to record the order you did it in, even though it
> doesn't actually matter.
You *can* do all 200 at once, if you want. It's just a mess to specify.
>> No, it doesn't really work like that. Like I said, of the Linux repo,
>> there's 240,000 commits, of which 15,000 are actually merges. Git has a
>> lot of ways of editing the history to make it look simpler, which is
>> where all the perceived complexity of git lies.
>
> I might suggest that if you *need* the ability to edit history to make it
> look simpler, you're doing it wrong.
One is editing history only to back out changes or rearrange commits. Once
it's in a repository anyone else can see, you can't edit it safely any more.
Just like Darcs.
> Except that with Darcs, you don't need to record the fact that a branch ever
> even existed. You just record what was done with the actual file contents.
I would classify that as a problem, not a benefit. I'd like to know which
patches were developed independently, when they were incorporated into the
current code, etc.
>> Well, here's the advantages of git, so far:
>>
>> Git can keep multiple branches in one repository
>
> I don't know how that works, but if you mean you can have multiple working
> copies, then yes, I guess that could be quite useful.
No. It's exactly like having multiple repositories in one directory.
Branching in git is cloning the repository in Darcs. Merging in git is a
pull in Darcs.
>> Git keeps track of where changes came from and when, so if I pull in a
>> 2-month-old changeset and it breaks something, I can figure out when I
>> pulled it in vs when you wrote the change.
>
> I'm not sure I see why you would need that information, but OK, Darcs can't
> tell you about that.
Because if you created a patch six months ago and I only applied it last
week, it would be good to know that when things start breaking, it *might*
be because of a change that I only saw a week ago, and I might have to go
back as far as six months worth of changes to understand the problem.
You really don't see the benefit of knowing the difference between "when I
wrote the code" and "when I gave you the code"? It's the same reason you
put version numbers on executable files you distribute - so you know what
you're running when.
>> git keeps a history that can tell me what changes rely on other changes
>> semantically, not just syntactically.
>
> How?
Exactly that "linear" order you're complaining about. The DAG of commits
tells you which changes were written with one version in mind but without
other changes in mind.
If I change on April 1 the semantics of function XYZ, then I write code on
April 3 depending on the new semantics, and you on April 5 write code
depending on the old semantics, you now have a dependency from your code to
the April 1 code that isn't recorded anywhere in Darcs. It's recorded in
git, tho.
If I have a repository and I merge in a bunch of your changes and apply
them, then I merge in a bunch of changes from Jim, I could very well get
tons of conflicts if Jim didn't apply your changes when he started working.
It seems fragile to me to have a working directory and a repository where I
can incorporate changes into the repository that I cannot get into the
working directory to work on.
>> git doesn't have to spend tens of hours applying 240,000 change sets to
>> the repository in order to give me the latest version of the files.
>
> Neither does Darcs.
Sure it does. Delete your working directory.
When you clone git, it pulls down the repository, then creates the working
directory from that. When you clone darcs, it sounds like it pulls down both
the repository and the working copy (which would seem problematic if the
working copy had changes to it that weren't recorded, yes?).
>> git has all kinds of sweet tools to manipulate the repository in ways
>> Darcs can't very easily.
>
> Ways such as what?
Like the bisecting command, just as an example. Or the stash command. Or
commiting things in phases. Or efficiently giving me a copy of the files as
they existed at a specific point in time. (Indeed, since Darcs doesn't
actually record what order you pulled changes in, it seems Darcs can't
really even do that inefficiently.)
>>> Still, until GHC moves from Darcs to Git, I won't have to actually
>>> care, so I guess it doesn't really matter.
>>
>> Not unless you wind up working on a project that uses git.
>
> That isn't going to happen.
BTW, if you ever want to play, there's a script for git that will import the
changes from and export to a Darcs repository.
http://vmiklos.hu/project/darcs-fast-export/git-darcs
Just from reading the comments, it looks like it stores the Darcs repository
as one branch of the git repository, treating it like a remote repository.
> 1. I will never wind up "working" on anything that's version-controlled. I
> am apparently doomed to spend the rest of my /working/ life rebooting
> people's PCs because Word crashed, rather than doing interesting coding tasks.
<Yoda> And that is why you fail. </Yoda>
> 2. If we're talking about hobby projects, obviously I'm going to pick one
> that uses my preferred tools.
Sure.
> It's not that I don't understand the difference between Git and Darcs. It's
> that I can't begin to comprehend how what Git does can work. It just seems
> such an obviously stupid way to approach the problem.
It seems like a tremendously elegant system to me, like the relational model
for version control. You have a big pile of snapshots, one for each
committed set of changes. All differences are calculated from the snapshots
as needed.
Darcs too is fairly elegant. If they had a more sophisticated way of
handling groupings of changes besides "clone the entire repository and then
make irreversable changes to it" it would be even better.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2011 10:48, Orchid XP v8 wrote:
> My general reaction being "don't do that",
Sounds like a problem for any dvcs. Some development cycles take a while,
you know? :-)
It seems like a problem exactly because darcs doesn't record what version of
the code you were using when you made a particular change. If I change
something "at the same time" as you change something that uses the old
version, there's nothing recording that you wrote that after I made my
change but before you actually knew about my change. *That* is the "linear"
bit you're complaining about in git.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/04/2011 06:46 PM, Darren New wrote:
> If you make the WD match
> the repository, then fetch changes without applying them, then ask for
> diffs, isn't Darcs going to tell you the WD doesn't match the
> repository?
Yes.
> If your change added the line ABC, isn't darcs diff going to
> tell you you removed ABC from the WD?
I'm not precisely sure what you're asking.
> So what do you mean "apply"? What happens if your WD matches the
> repository, then you do a fetch, then you say "record", what does Darcs do?
Records a new patch reverting all the changes that you didn't apply,
presumably. (Of course, what it's *actually* going to do is prompt you
for which ones you want to record, but anyway...)
>> It's the fact that you have to commit the merged version of the file as a
>> new version. Every time you merge in a new change, you have to commit
>> a new version. It just seems clunky and unecessary.
>
> It's mildly clunky, but it tells you which changes are applied to which
> snapshots. git does this because it records files, not changes, yes.
> It's probably the part of git that people like least.
It's the part I least like, at any rate.
> What happens if I have a number of tags in the repository (v1 and v2 and
> the current v3 under development), and I want to apply a bugfix to the
> v1 version that doesn't apply to the later versions? How do I do that?
You can't really use tags for that; you'd have to have seperate repos
for v1, v2 and v3. Oh, you *can* put all the patches in one repo, but
it's going to get messy very quickly.
> I might want the development branch to apply the changes but not the
> branch that's half way thru QA testing.
The Darcs way to do this is to store copies that are meant to be
different in different places - which seems fairly logical to me.
(Admittedly a little inefficient on disk space...)
>> Oh, I see. You mean if you actually have multiple versions of something
>> being developed concurrently? Yeah, in that case you'd have to move the
>> changeset from one branch to another and hope it works.
>
> And *that* is exactly what a git merge is. You don't do a merge every
> time you record a change. You only do a merge when you're actually, you
> know, merging two sets of changes into one branch of the repository.
You don't do a merge every time you record a change. You do a merge
every time somebody *else* records a change.
> A git branch is like a darcs repository.
> A git commit is like a darcs record.
> A git merge is like a darcs fetch-and-apply.
Except that you don't explicitly keep a record of a darcs fetch-and-apply.
>> So if two people have the same repo, and they merge in change X and then
>> later merge in change Y, and then the other guy merges in change Y
>> first and
>> later change X, they now apparently have conflicting histories.
>
> Well, you don't really "merge in" a change. You merge a change from one
> branch to another. You're not merging changes, you're merging branches.
>
> You're not going to have conflicting histories. Indeed, you *can't* have
> conflicting histories because history is immutable. You might have
> different histories in each repository, but that's like having two Darcs
> repositories cloned from the same source but with a different set of
> changes in each.
So what you're saying is, the histories in two Git repos don't actually
have to match, only the file contents?
>> (And all
>> because Git wants to pretend that everything happens in linear order.)
>
> No, git very specifically does *not* pretend things happen in a linear
> order. There's all kinds of tools to examine the DAG of dependencies
> between versions.
OK, "linear order within a single branch".
>> As I say, it just annoys me that you have to assign an arbitrary
>> ordering to changes.
>
> It's not really arbitrary. Darcs just ignores the fact that they aren't.
>
> If I add function AAA to file BBB and record that change, then add a
> call to function AAA into file CCC, then record that change, would that
> really be independent unordered changes in Darcs? That seems awfully
> fragile.
Darcs doesn't guarantee that a particular combination of patches will
produce a working combination of files. Neither does Git, or RCS, or
CVS. Git /assumes/ that if you apply the changes in the same order that
the author did, this is more likely to produce a working configuration,
but there's no /guarantee/ at all.
Changes have descriptions for a reason.
>>> Say you have 25 changes in your Darcs repository, and you want a version
>>> that applies every change except #23. What do you put in the repository
>>> to represent that?
>>
>> You ask Darcs to revert change #23.
>
> And how do you do that? "darcs revert" doesn't do that. "darcs unrecord"
> throws the change away entirely. Obliterate deletes the patch entirely
> as well.
"darcs rollback" does it though.
> Patches within any one branch have a linear time ordering. But git
> handles multiple branches in the same repository. So changes between
> branches aren't linearly ordered.
OK, fair enough. But changes within a branch are linearly ordered.
> For example, attached is a picture of the last few dozen commits to the
> Linux kernel.
What we see here is a long tangled history of sequential changes, rather
than a set of mostly independent changes which could safely be combined
in any combination.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2011 10:38, Orchid XP v8 wrote:
>> git has all kinds of sweet tools to manipulate the repository in ways
>> Darcs can't very easily.
>
> Ways such as what?
Here's another example of something I don't understand how to do in Darcs.
Say you and I are both working on the same program. I find a bug in function
ABC that needs a counter incremented in a loop. At the start of the loop, I
add the counter increment. You, at the "same time", find the same bug and
fix it by adding the counter increment to the end of the loop.
Now, when we merge repositories, we'll be incrementing the counter twice.
OK, not a problem that a VCS can solve, and you'd get the same ugly in git.
But ... OK, so I see you fixed the bug by adding the counter at the bottom,
and since I already fixed it, I throw away that change from my repository.
You see you already fixed it, so you throw away my change in *your* repository.
How do we reconcile that later? How often do I have to exclude your change
from my repository (while still obtaining your other changes), or how do I
tell you to throw away your change and use mine instead?
In git, I'd manipulate the branch structure, or possibly rebase my changes,
or I'd revert out that one change from my code during the merge and continue
on. But since Darcs apparently doesn't record "they both started from the
same place and made changes in parallel",
I don't see how Darcs can rationally handle the *history* of this change,
other than having one or the other of us record a change that deletes the
line that we added, then distributing that change around. I.e., I don't see
how you can say "add this line, but delete that line it only if you apply
the patch that fixes the problem elsewhere" in any sort of managable way.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Apparently this doesn't stop people working on the Linux kernel. But it
>> seems really clumsy to me.
>
> It seems clumsy because you keep thinking git is recording changes. You
> keep thinking of "changes" instead of "versions".
That's because "changes" are the logical thing to think about. Take a
look at a bunch of commit messages, and they all tell you about what
just *changed*.
>> Last time I tried downloading the repos for GHC, it was dominated by
>> network latency. Processor usage was almost non-existent.
>
> Yep. But you only got the latest version. If you wanted to get every
> tag, you wind up copying all those files again anyway.
Um... why? The tags are downloaded along with all the rest of the history.
Or perhaps you meant if I wanted GHC-6.6 and GHC-HEAD? In which case, I
gather that Darcs caches patches which have recently been downloaded, so
I would only have to download the handful of patches which are actually
different between the two.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2011 11:55, Orchid XP v8 wrote:
>> If your change added the line ABC, isn't darcs diff going to
>> tell you you removed ABC from the WD?
>
> I'm not precisely sure what you're asking.
If I bring my WD up to date, then I fetch changes, then say "record", isn't
that going to record a diff that backs out all your changes?
>> So what do you mean "apply"? What happens if your WD matches the
>> repository, then you do a fetch, then you say "record", what does Darcs do?
>
> Records a new patch reverting all the changes that you didn't apply,
> presumably.
That sounds really dangerous to me.
>>> It's the fact that you have to commit the merged version of the file as a
>>> new version. Every time you merge in a new change, you have to commit
>>> a new version. It just seems clunky and unecessary.
>>
>> It's mildly clunky, but it tells you which changes are applied to which
>> snapshots. git does this because it records files, not changes, yes.
>> It's probably the part of git that people like least.
>
> It's the part I least like, at any rate.
The tool that shows history has options to leave out commits that are
nothing but merges without any other changes. :-)
>> What happens if I have a number of tags in the repository (v1 and v2 and
>> the current v3 under development), and I want to apply a bugfix to the
>> v1 version that doesn't apply to the later versions? How do I do that?
>
> You can't really use tags for that; you'd have to have seperate repos for
> v1, v2 and v3. Oh, you *can* put all the patches in one repo, but it's going
> to get messy very quickly.
See, git has no trouble with that. One repo has all of every version of
Linux since 2.6.16 or so.
>> I might want the development branch to apply the changes but not the
>> branch that's half way thru QA testing.
>
> The Darcs way to do this is to store copies that are meant to be different
> in different places - which seems fairly logical to me. (Admittedly a little
> inefficient on disk space...)
And a bit fragile. The idea of git is that you have a repo with all the
history in it. You don't have to chop it into multiple repos in order to
actually exclude some of the history from here and there.
> You don't do a merge every time you record a change. You do a merge every
> time somebody *else* records a change.
No, you do a merge every time you want to *apply* someone else's changes to
your working directory.
>> A git branch is like a darcs repository.
>> A git commit is like a darcs record.
>> A git merge is like a darcs fetch-and-apply.
>
> Except that you don't explicitly keep a record of a darcs fetch-and-apply.
Exactly. Which seems like a downside to me more than an upside. It means you
have to have separate repos for different versions of the same program,
duplicating all that history and making it "fragile" in the operational
sense (as in, too easy to accidentally update a repo with changes that
shouldn't be there, with no easy way to remove those changes since the fact
that you fetched them isn't recorded).
> So what you're saying is, the histories in two Git repos don't actually have
> to match, only the file contents?
The histories merge if two histories bring you to the same set of contents.
Indeed, since each file is stored with a name based on the hash of its
contents, it's literally impossible to have the same content in two
different files.
> OK, "linear order within a single branch".
Yes. And that's a *good* thing, I'd posit, for the reasons I mentioned in
other threads.
>>> As I say, it just annoys me that you have to assign an arbitrary
>>> ordering to changes.
>>
>> It's not really arbitrary. Darcs just ignores the fact that they aren't.
>>
>> If I add function AAA to file BBB and record that change, then add a
>> call to function AAA into file CCC, then record that change, would that
>> really be independent unordered changes in Darcs? That seems awfully
>> fragile.
>
> Darcs doesn't guarantee that a particular combination of patches will
> produce a working combination of files. Neither does Git, or RCS, or CVS.
Yes. But more than that, Darcs doesn't record what your WD looked like at
the time you created the changes. *That* is the problem.
In Darcs, I'd have much more trouble tracking this bug down. In git, I'd be
able to see that you created your patch before you knew about my change to
function AAA, and maybe that's the source of the problem. In Darcs, I don't
think I have any way of looking at your patch to CCC and saying "what
version of file BBB was he reading while he was writing file CCC?"
> Changes have descriptions for a reason.
A manually-entered description isn't going to say what versions of the files
you *didn't* change you were relying on. That's where the commit history in
git helps out.
>>>> Say you have 25 changes in your Darcs repository, and you want a version
>>>> that applies every change except #23. What do you put in the repository
>>>> to represent that?
>>>
>>> You ask Darcs to revert change #23.
>>
>> And how do you do that? "darcs revert" doesn't do that. "darcs unrecord"
>> throws the change away entirely. Obliterate deletes the patch entirely
>> as well.
>
> "darcs rollback" does it though.
Oh, OK. But again it makes a permanent change in the repository. I guess
you'd have to clone the entire repository, then roll back that one patch.
> OK, fair enough. But changes within a branch are linearly ordered.
Yes, and that's a good thing. You can trivially reorder them if they're
independent, but there's no way of knowing whether they're really
independent. Git assumes they aren't, and if they are, you can reorder them
if you care. Darcs assumes they are unless you tell it so.
>> For example, attached is a picture of the last few dozen commits to the
>> Linux kernel.
>
> What we see here is a long tangled history of sequential changes,
I'm not sure how you get a tangle of sequential changes. What does that even
mean?
> than a set of mostly independent changes which could safely be combined in
> any combination.
Each of those strings of sequential history is a set of independent changes.
I don't think Darcs is any less tangled, or to the extent it is, I'm not
sure it would be accurate to rearrange them.
Might I ask, why do you care? You're talking about a VCS being a record of
the history of changes, and your biggest complaint against git seems to be
that it's actually recording the history of changes. Darcs seems to throw
away useful information about the history of the changes in the hope that it
can automatically deduce enough of the history not to break in the future.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2011 12:14, Darren New wrote:
>> "darcs rollback" does it though.
>
> Oh, OK. But again it makes a permanent change in the repository.
It also sounds like it would be sketchy if #24 depended on #23 (or even
changed something else #23 changed) and now your rollback patch has a merge
conflict? Or your rollback patch has a merge conflict with someone else's
changes?
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2011 11:58, Orchid XP v8 wrote:
>>> Apparently this doesn't stop people working on the Linux kernel. But it
>>> seems really clumsy to me.
>>
>> It seems clumsy because you keep thinking git is recording changes. You
>> keep thinking of "changes" instead of "versions".
>
> That's because "changes" are the logical thing to think about. Take a look
> at a bunch of commit messages, and they all tell you about what just *changed*.
No. The history is the logical thing to think about. Commits are a logical
thing to think about. Changes are *one* logical thing to think about, but I
think it's easier to generate changes from history than to generate history
from changes, especially when changes aren't in any particular order.
In other words, changes don't represent all the history. You're throwing
away the history of "clone" and "pull" and "push" and "apply". All you're
recording is the changes to the files in the WD, not changes in the
repository itself.
> Or perhaps you meant if I wanted GHC-6.6 and GHC-HEAD?
No, I meant if I wanted to compile each tagged version in the repository. I
want to compile GHC-1.0, GHC-1.1, GHC-1.2, GHC-2.0, ....
I have to basically apply every patch in sequence in the entire repository,
in some unknown order.
In git, all those files are already there. If it's packed, you might wind
up applying a lot of patches, but the patches are optimal in that case,
rather than an accident of history.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> git keeps a history that can tell me what changes rely on other changes
>>> semantically, not just syntactically.
>>
>> How?
>
> Exactly that "linear" order you're complaining about. The DAG of commits
> tells you which changes were written with one version in mind but
> without other changes in mind.
In other words, Git is *guessing* which changes depend on each other
semantically from which changes were written at the same point in time
in the same repo.
I could change thing X, and then change thing Y which has nothing to do
with thing X, and still Git will assume a relationship exists there.
Darcs, on the other hand, only concerns itself with *real* dependencies.
It's true Darcs can't guarantee that a particular combination of patches
will produce runnable code. It's also true that Git can't guarantee that
the code in any particular commit object is runnable either.
> If I change on April 1 the semantics of function XYZ, then I write code
> on April 3 depending on the new semantics, and you on April 5 write code
> depending on the old semantics, you now have a dependency from your code
> to the April 1 code that isn't recorded anywhere in Darcs. It's recorded
> in git, tho.
For every true dependency, there will be a bazillion spurious ones. So
it's a case of "Which is worse? Missing some real dependencies, or
recording millions of fake ones?" Given that the former is much simpler
conceptually, I'll go with that thanks.
> If I have a repository and I merge in a bunch of your changes and apply
> them, then I merge in a bunch of changes from Jim, I could very well get
> tons of conflicts if Jim didn't apply your changes when he started working.
Is this not the case for every known distributed version control system?
> It seems fragile to me to have a working directory and a repository
> where I can incorporate changes into the repository that I cannot get
> into the working directory to work on.
Why can't you get them into the working directory?
>>> git doesn't have to spend tens of hours applying 240,000 change sets to
>>> the repository in order to give me the latest version of the files.
>>
>> Neither does Darcs.
>
> Sure it does. Delete your working directory.
>
> When you clone git, it pulls down the repository, then creates the
> working directory from that. When you clone darcs, it sounds like it
> pulls down both the repository and the working copy (which would seem
> problematic if the working copy had changes to it that weren't recorded,
> yes?).
Wrong.
It doesn't pull down the working directory at all. Indeed, in the copy I
put on my webserver, I *deleted* the working directory.
It pulls down the *pristine* copy, which contains only recorded changes.
[And is compressed.] If you're silly enough to delete that, then you
just broke your repo. (I'm not sure whether the repair command can fix
this... I believe so, but I've never tried it. It probably won't be fast
though.)
>>> git has all kinds of sweet tools to manipulate the repository in ways
>>> Darcs can't very easily.
>>
>> Ways such as what?
>
> Like the bisecting command, just as an example. Or the stash command.
Without looking those up, I don't know what they do.
> Or commiting things in phases.
You mean like if you go to record something and realise you want to
tweak it first?
> Or efficiently giving me a copy of the files
> as they existed at a specific point in time. (Indeed, since Darcs
> doesn't actually record what order you pulled changes in, it seems Darcs
> can't really even do that inefficiently.)
You could add a tag before you pull anything in. Then if you have
problems, you can go back to the tag. (Or just query exactly what
happened after the tag.) But yes, I suppose the fact that you need to
remember to do this could be considered a weakness. There's no really
fundamental reason why Darcs couldn't keep a history of what's happened
to your repo though. (And keep it local to that repo, not part of the
shared change history.)
> BTW, if you ever want to play, there's a script for git that will import
> the changes from and export to a Darcs repository.
Given the radically different ways in which the two systems work, I
imagine the history gets pretty mangled in the conversion - no matter
which system you believe is the "correct" one.
>> 1. I will never wind up "working" on anything that's
>> version-controlled. I
>> am apparently doomed to spend the rest of my /working/ life rebooting
>> people's PCs because Word crashed, rather than doing interesting
>> coding tasks.
>
> <Yoda> And that is why you fail. </Yoda>
Is this the same Yoda who lived in a universe where you can literally
make inanimate objects physically move just by *believing* that you can?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
