On Thu, 2006-05-11 at 10:38, Darren J Moffat wrote:
> George Wilson wrote:
> > This would be comparable to what live upgrade does with its sync option.
> > With lu, certain files get synced to the newly activated BE just prior
> > to booting it up. (see /etc/lu/synclist)
>
> even in that file there are three different policies:
>
> OVERWRITE, APPEND, PREPEND.
This situation is analogous to the "merge with common ancestor"
operations performed on source code by most SCM systems; with a named
snapshot as the clone base, the ancestor is preserved and can easily be
retrieved.
there's a real opportunity here to enhance packaging class action
scripts to allow for a file-format-specific three-way merge when
conflicting changes are detected on both "branches".
for editable files, packaging squirrels away an unmodified copy so there
are actually four or five different versions which might conceivably
provide input to different stages of an upgrade.
the merge ladder looks like:
0 ---dev-----> 1
| |
v v
2 ---upgrade-> 4
| |
v v
3 ---sync----> 5
key:
0) old release unmodified; (preserved in old BE pkging)
1) new release unmodified; (preserved in new BE pkging)
2) running system at time of LU copy (preserved via zfs snapshot)
3) running system at time of cutover (old BE contents)
4) upgraded system (new BE contents, pre-sync)
5) system after luactivate+reboot (new BE contents, post-sync)
"dev" : solaris development (change to source packages)
"upgrade": package upgrade as part of luupgrade
"sync": post-LU resynch to catch any changes from operation.
- Bill
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
