On 2007-07-18 15:35, Vladimir Marek <[EMAIL PROTECTED]> wrote:
>[...]
>> What "wx backup" does is stores a consistent set of SCCS s., p. files
>> along with the checked out and writeable version.
>
> Basically everything sccs needs to be placed to 'previous' state.
Indeed. But I'm not sure if what is described below is an easy way to
do this.
> I'm afraid that for Mercurial this might be bigger challenge, since hg
> uses in addition to actual files and .i files (.i is similar to .s for
> sccs) also some index files. We will need to understand all files in
> .hg and decide which of them are about to be stored to the backup.
>
> Or maybe backup whole .hg, excluding .i files which were not touched ?
>
> Also how do we know which files we touched? Will wx for Mercurial also
> have the 'active' file list?
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.
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
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.
* 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.
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'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.
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" :-)
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
