[... backup ...] > > Or maybe backup whole .hg, excluding .i files which were not touched ? > > > Then "wx" would need to internalize knowledge about the 'revlog' storage > format of Hg. This may be either difficult or not stable enough for > future updates to .hg/* files. > > Even though the storage format of Mercurial has changed only once so > far, I am not sure I would bet on making the binary format of *.i and > *.s files something which "wx" or a similar tool depends heavily upon.
Being dependent on a binary mess is not the best thing, that's right. So
the question is if we suppose to restore from old backup anytime later,
or just for some short time. wx backup stores just the files you
touched. But since whole source tree probably evolves over time, I would
guess that the backup will not be very valuable in long term. From this
perspective we might tolerate the dependence on a binary mess.
> AFAICT, there are two things which have to be stored for a reliable
> backup of a child workspace:
>
> 1. Local committed changes
>
> 2. Local uncommitted changes
3. File renames/deletes ? Any wx guru who knows what else is stored ?
> These can be stored and restored later without MQ, since using MQ to
> keep this sort of information around may be too "alien" for wx users.
>
> Storing the changes may be something similar to:
>
> * Local committed changes:
>
> This can be saved in a 'bundle' file, with:
>
> $ hg bundle ~/hg.backup/foo.bundle parent-workspace-path
>
> Since a 'bundle' can be used to completely reconstruct the full
> changeset ancestry for locally committed changesets, and it's
> supported well enough by the current Mercurial implementations,
> it's probably good enough for this part of a "wx backup" operation.
Wouldn't it mind if the parent workspace changed the same files at the
same time ?
> * Local uncommitted changes:
>
> If changes have been made to the tree, but they haven't been added
> to the active changes with "hg add", "hg rm" or other hg operations,
> it may be necessary to run "hg addremove" first.
>
> Then, the 'active' files can be seen with:
>
> hg diff --git > ~/hg.backup/foo.uncommitted
>
> The generated patch can be stored in the same location as the bundle
> of locally committed changes.
I'm trying to imagine other option. Do hg diff > foo.uncommitted. Then
do hg status and add new files (and removed?) to the foo.uncommitted.
This would not force you to run addremove.
> Then "wx restore" would have to do the following steps:
>
> 1. Clone the parent/reference workspace
>
> 2. Pull from the stored bundle at ~/hg.backup/foo.bundle
>
> 3. Re-apply the git-style patch of the uncommitted changes from
> ~/hg.backup/foo.uncommitted and run "hg addremove" to make the
> applied patch appear as local changes.
>
> This would leave the workspace in a state that is identical to the one
> it had after the "hg addremove" operation of the backup stage.
I can imagine one difference from current wx backup/restore. Currently
you can do
wx restore uncommitted1
wx restore uncommitted2
and you will be in uncommitted2
However with patches, you will have to revert to 'clean' state before
going to another backup. This would mean that you have to know the
revision of 'clean' state. But this can be noted down during 'wx init'
or 'wx bringover'. I'm not sure how bad this impact would be to users.
> I've used the first two steps (clone & pull from bundle) with a fair
> amount of success for several Hg workspaces, but I'm a bit fuzzy about
> how the last one (applying a git-style patch of the local but as of yet
> uncommitted changes) would be possible.
I do not know what's git-style patch at all :) Any idea what is the
difference against normal patches?
> Maybe we could convince the Hg developers to add an option to the
> existing "import" command of Mercurial, which applies a git-style patch
> but doesn't *commit* the imported changeset as the new tip revision.
>
> That would nicely fit as the third part of a "wx restore" :-)
So you can't apply git-style patch by patch < my_diff ?
--
Vlad
pgp3YKPnbSvJP.pgp
Description: PGP signature
_______________________________________________ tools-discuss mailing list [email protected]
