Re: [Arx-users] Wedged another archive

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> > Correct.  If "patch" could have applied the patch, it already would
> > have.  To resolve the patch, you resolve it by hand by cutting and
> > pasting appropriate lines from the .rej file.  Alternately, if you're
> > using emacs, you can use the prescription I linked to earlier.
> 
> Any idea if xxdiff is capable of handling this? Will meld work
> if/when I can get it installed?

I have both, and neither is really suitable for .rej files.  You
really have to use an editor.

> I have no interest in learning emacs, so that's not an option for
> me.

Oh, it's not so bad.  However, for the general case, it would
certainly be nice for people to be able to use whatever tool they
want.

> > Switch the order of the merge commands.  So where you originally did
> > something like
> > 
> >   arx merge merged_arx address@hidden/arx.2.1 address@hidden/arx.kevins
> > 
> > instead do
> > 
> >   arx merge merged_arx address@hidden/arx.kevins address@hidden/arx.2.1
> 
> Hm. Is it abnormal that I feel drawn to doing my merging in-place? Maybe 
> that's one of the main reasons I keep ending up wedged. It just feels 
> wrong to me to create a whole new tree just to pull in some changes. 
> Perhaps you could provide a little of the philosophy to help me 
> understand why in-place would be worse (or better) than the new tree method.

Not doing things in-place means that if you totally mess up, you can
just remove the whole tree and start over.  If you have committed all
of your changes, then there is really no difference between the two.

> [Side note: One of the things that irritates me about darcs is that it 
> always wants you to create new trees for everything. On Linux, it uses 
> hard links, but on Windows or on a cheap web host, that's not an option. 
> It always bothered me a bit, from a purist theoretical standpoint.]
> 
> > Agh!  You probably should not have run delete-revision.  I should put
> > more warnings and make it more difficult to use.  It is really only
> > meant for removing things that should not be in the archive (e.g. huge
> > binaries, kiddie porn).
> 
> Ok. But shouldn't it have automatically built a new checksum file, or 
> otherwise managed to leave the archive in a usable state? For now, the 
> docs should at least say that it will leave the archive in an unusable 
> state. I was only deleting the most-recent change, after all.

Well, you deleted that revision, so that revision is definitely no
longer useful.  There is not much you can do about that.  However, ArX
seems to want to use it when it shouldn't (see below).

> > This is a bug.  This should have worked.  In the meantime, try tagging
> > instead
> > 
> >   arx tag address@hidden/arx.kevins,1 address@hidden/arx.kevins
> 
> address@hidden arx $ arx tag address@hidden/arx.kevins,1 
> address@hidden/arx.kevins
> No such revision in the archive
>          address@hidden/arx.kevins,2

Do you have a copy of the old tree around with that revision in the
tree cache?  I think that is what is causing your troubles.  You need
to delete them and any archive caches as well (though ArX really
should delete any archive caches by itself).  Admittedly, ArX
shouldn't be trying to get such a revision anyway.  More on the TODO
list.

> > In any case, what you really wanted to do was something like
> > 
> >   arx get address@hidden/arx.2.1 wlandry_arx
> >   arx history --dir wlandry_arx --add address@hidden/arx.kevins
> >   arx tree-branch address@hidden/arx.kevins
> >   arx commit -s "Reverted to wlandry's code"
> > 
> > That will create a revision that reverts all of the changes that you
> > made, but still records that you made those changes.  This is
> > described in Section 5.8.2.1.
> 
> Yeah. It seemed icky when I read the general docs, and it seems just as 
> icky when I see the specific version here. It looks like we're creating 
> another tree.

If it makes you feel better, you can delete your current tree.

> The history command still seems awkward (and error prone) to me. I
> guess the whole sequence just seems like a counter-intuitive way to
> accomplish the goal. I'm not sure I would have been able to figure
> out the above steps on my own.
> 
> Maybe what I really want is a nice gui that hides all this from me. I 
> guess I've been spoiled by the eclipse cvs plugin that actually makes 
> cvs seem decent, even when merging conflicting work from other 
> developers. I may write a gui tool for ArX, if I can figure out what I 
> want it to do.

I am not sure that there is much that can be done to improve this.
You do have to get the old revision, add the patch logs, and commit.
I could make a new command to do just this, but I don't think it is
done often enough to warrant it.

> I'm trying to remain optimistic about all this. I know that ArX hasn't 
> been used heavily by very many people yet (and especially people like me 
> who only use 10% of revision control features). As long as all these 
> kinds of issues are "solveable" (via functionality changes, better 
> prompting, more docs, external tools, etc), I'm not worried.

For this particular case, there is a straightforward way to solve
this: modify ArX to use diff3 with "merge".  Not too difficult, but it
is some work.  Then you would not have been driven to the other
alternatives.

Walter