Hello Maurice!
> When an "fsvs up" aborts after having updated a few files already, those
> files are marked as changed. The next "fsvs up" will fail with:
>
> The entry ... has changed locally. (where ... is one of the updated files).
Yes, that's a known problem. (At least for me.)
Long answer:
I'd like to avoid having to put a complete atomic layer (like svn has) into
FSVS; my
preferred solution is to use a unionfs.
1) Create a new namespace
2) Mount an empty directory via unionfs above your WC
3) Run FSVS up; all changes are done in the overlayed directory
4) Mount the (now non-empty) directory in the normal namespace.
That means an atomic change to the updated data - if it's 10kB or 10GB.
5) Use unionfs_merge to move the changes from the overlayed directory to the
base
(does removed entries, too)
6) Remove the overlayed directory
7) Profit!
That's *really* atomic.
svn's copy-locally, then move is good enough for sources; but for binaries and
shared
libraries it's no use, because you'll have inconsistent states in-between,
where the
binaries don't match the libraries.
> When asked for the differences, fsvs will show the differences between
> the updated file and the previous revision from the archive (the
> revision at which the work area was before the aborted update I suppose).
Yes, because the filelist was not written - and so FSVS compares against the
old revision.
When I get mixed working copies working, I can at least try to write the
current state
to disk - then you just get some mixed state, but not this problem.
> What I can't figure out though is why it aborts the original update.
FSVS should be able to detect conflicts *before* fetching file-data from the
repository.
If it doesn't, that's a bug.
But why does it abort for you? Do you have some error message?
> Here's a sample session (alias status="fsvs -C -f text,owner,group,mode"):
...
> 20 goto 10 ;-)
No, this is C; you'll need a label for that :-)
I see the problem you describe; by why does FSVS stop in the first place?
> This is revision 1881 from svn, but my metadata may be from an older version.
The meta-data hasn't changed lately (but will soon).
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
