On Tue, 30 Aug 2011 11:38:08 -0400 Martin Gagnon <[email protected]> wrote:
> From my CVS background, I'm use to do dry run before every update or > commit I do. For CVS it's absolutely necessary, since there's no undo > command and for some operation, when there's conflict, it can produce > a big mess on local files. > > When I start using fossil, I keep same habit with update. I use fossil > update -n pretty often.But when autosync is on, the "-n" of fossil > doen't really show what the real update would do, since with "-n" the > "pull" part is skipped. Normal since there's no "dryrun" option for > pull/push/sync operation. [...] Could you please explain what's the precise use case for "-n"? Suppose I do `fossil update -n foo` and it shows me there would be a conflict--what am I supposed to do in this case? Stash the uncommitted changes and re-try? But if I want my changes applied on top of that revision "foo" I'll need to deal with the merge anyway, so what's the point? (Please note that I've got a Git mindset so I'm honestly curious about this use case.) Also how about the fact there's an inherent race condition between adjacent calls to any fossil command which interacts with a remote repo: you can run `fossil whatever --dry-run` and see everything's OK and then the next call to it will hit a modified state of that same repo because some other developer happened to update it in the meantime. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
