On Wed, Jul 18, 2007 at 05:15:11PM +0200, Vladimir Marek wrote: > [... 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 ?
I have some idea. 8^) wx backs up: 1. files in the active list including the SCCS s. and p. files (if the file is checked out). 2. The wx new list which is a wx state file that tracks newly created files in the workspace. 3. The wx renamed list (files that have been renamed in the workspace). 4. The wx sort_active state file (indicates user's preference in regards to wx keeping the active list sorted). 5. The wx *.NOT files which allow the user to record files which are exempt from certain wx putback checks like cstyle, etc... 6. The wx local_nametable file which is a subset of the local workspaces nametable containing the entries associated with the active, new and renamed lists. While generating this list I realize that wx should also backup the wx/backup_dir file but I haven't seen too many complaints about this so I'm not going to worry about it. > > 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 Certainly that was my intention when I wrote wx restore. > 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. -- Will Fiveash Sun Microsystems Office x64079/512-401-1079 Austin, TX, 78727 (TZ=CST6CDT), USA Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay Info about krb-diag: http://kerberos.sfbay/krb-tool-info.html _______________________________________________ tools-discuss mailing list [email protected]
