On Tue, 29 Oct 2013 12:53:59 +0100, Richard Hipp <[email protected]> wrote:
The "fossil update" command does a "fossil pull" in autosync mode. The
"fossil commit" command first does a "fossil pull", then does the
check-in,
then does a "fossil push".
This has nothing to do with content. The sync mechanism in Fossil does
not
distinguish between wiki or tickets or checked-in files. When you sync
or
push or pull, it applies that operation to everything. There is no
mechanism in Fossil that will sync only check-ins or only wiki, etc. It
is
all or nothing.
I principally have not thought otherwise. the "problem" is that wiki
changes are not "commit"ed but are done (and integrated into the repo) via
the ui.
The issue here is that with "fossil up" you are only doing a "fossil
pull"
yes, I realized the `pull only' associated with `up' a bit late, i.e. only
after sending the original mail...
and a pull does not move content from the local repo to the remote repo,
by
design.
And I'm pretty sure that I do NOT want "fossil up" to do an unannounced
push.
you are probably right. sorry for the noise. --
regarding point no. 2 (documentation of `up'), I still think these things
(first sentence of your reply, essentially) should be mentioned there (and
for `fossil help commit', too).
moreover, here
http://www.fossil-scm.org/index.html/doc/tip/www/quickstart.wiki
it says:
"The default behavior***s*** is for autosync to be turned on. That means
that a pull automatically occurs when you run update and a push happens
automatically after you commit. So in normal practice, the push, pull, and
sync commands are rarely used. But it is important to know about them, all
the same."
apart from the indicated typo: this is clear w.r.t. to `up' not doing a
`push', but not w.r.t. `ci' first doing a `pull'.
On Tue, Oct 29, 2013 at 4:11 AM, j. van den hoff
<[email protected]>wrote:
two things:
1.
in autosync mode, one can do `fossil up' to pull/push changes and
integrate them into the checkout which mostly prevents unnecessary
forking
etc. this is (for good reason) listed as one notable advantage of
`fossil'
over other DVCSs.
however, (local) changes to the wiki pages are ignored by `fossil up',
i.e. are not propagated to the remote repo. o.t.o.h. after `fossil ci'
the
wiki changes _are_ propagated, together with the checked-in (file-)
modification.
but w/o doing a checkin, in order to actually sync the wiki changes, I
have to issue `fossil sync, fossil up' (the latter to integrate remote
changes into the checkout).
question: should not `fossil up' also honor wiki edits (and tickets,
events), too, in autosync mode?
the present behavior (`up' ignores wiki, `ci' syncs wiki changes, too)
feels a bit inconsistent (not claiming that it really is...).
2.
`fossil help up' does not include any information what happens (and what
not) in autosync mode (neither to files, nor to wiki edits etc), but it
should.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
______________________________**_________________
fossil-users mailing list
[email protected].**org <[email protected]>
http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
