NB// there are two general contexts for a merge, merge from a branch or
merge from a node. When merging from a node there is no ambiguity and this
conversation does not apply. However when merging from a branch there *is*
ambiguity. The don't sync crowd sees the merge as applying to the tip of
On Mon, 13 Oct 2014 10:12:02 +0200, Ramon Ribó ram...@compassis.com
wrote:
NB// there are two general contexts for a merge, merge from a branch or
merge from a node. When merging from a node there is no ambiguity and
this
conversation does not apply. However when merging from a branch there
[Default] On Mon, 13 Oct 2014 10:29:36 +0200, j. v. d. hoff
veedeeh...@googlemail.com wrote:
On Mon, 13 Oct 2014 10:12:02 +0200,
Ramon Ribó ram...@compassis.com wrote:
On Sun, 12 Oct 2014 18:58:25 -0700,
Matt Welland estifo...@gmail.com wrote:
[]
autosync. For
most of us bandwidth is
On Sun, Oct 12, 2014 at 9:58 PM, Matt Welland estifo...@gmail.com wrote:
Auto sync before merge and after tagging would have saved me a few support
calls from confused users over the past few years :)
The after tagging: part I agree with.
*Maybe* in the case of bringing in the latest from
On Fri, Oct 10, 2014 at 8:01 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Oct 10, 2014 at 10:10 PM, Ross Berteig r...@cheshireeng.com
wrote:
Personally, I wouldn't expect that at all. The fossil merge command
edits the currently open workspace based ...
+1
The fossil update
If autosync is activated, of course it should do it. In fact, I see it
as an error not doing it. Does not 'autosync' means: do all the pushes
and pulls necessary to keep local repository always syncronized with
remote repository?
RR
2014-10-10 0:04 GMT+02:00 Matt Welland estifo...@gmail.com:
On Fri, Oct 10, 2014 at 10:01 AM, Ramon Ribó ram...@compassis.com wrote:
If autosync is activated, of course it should do it. In fact, I see it
as an error not doing it. Does not 'autosync' means: do all the pushes
and pulls necessary to keep local repository always syncronized with
remote
On Fri, Oct 10, 2014 at 9:08 AM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Oct 10, 2014 at 10:01 AM, Ramon Ribó ram...@compassis.com wrote:
If autosync is activated, of course it should do it. In fact, I see it
as an error not doing it. Does not 'autosync' means: do all the pushes
and
As a general observation, I would say that options is the ONLY option to
allow multiple mentalities to co-exist! And, I just proved it! :)
-Original Message-
From: Ramon Ribó
Sent: Friday, October 10, 2014 11:32 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] auto
On Thu, Oct 09, 2014 at 03:04:31PM -0700, Matt Welland wrote:
On Thu, Oct 9, 2014 at 12:43 PM, Richard Hipp d...@sqlite.org wrote:
I just did a fossil merge $BRANCH for some changes that a
colleague checked in, and was puzzled to not see much change in
the code. After I while, I
On Fri, Oct 10, 2014 at 3:14 PM, Martin Gagnon eme...@gmail.com wrote:
+1 for the warning message...
...Moreover, is it necessary to prompt user to continue or not if a pull is
needed? Or we rely on the undo command if the user want to pull before
merge ?
i agree it's a mildly annoying
On Fri, 10 Oct 2014 15:23:31 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Fri, Oct 10, 2014 at 3:14 PM, Martin Gagnon eme...@gmail.com wrote:
+1 for the warning message...
...Moreover, is it necessary to prompt user to continue or not if a
pull is
needed? Or we rely on the undo
+1
On 10 October 2014 09:38, j. v. d. hoff veedeeh...@googlemail.com wrote:
so I still would argue for leaving this area as it is right now. it really
is not _that_ much of a hassle to actually first pull (or update, if autosync
is
ON) before doing the merge and it somehow seems wrong that
On Fri, Oct 10, 2014 at 9:23 AM, Stephan Beal sgb...@googlemail.com wrote:
i agree it's a mildly annoying thing to have happen (and an 'undo' fixes
it, doesn't it?), but i'd find any pulling done by merge to be quite
surprising. i want to be guaranteed that if i run fossil merge X two
times
Thus said =?UTF-8?Q?Ramon_Rib=C3=B3?= on Fri, 10 Oct 2014 10:01:47 +0200:
If autosync is activated, of course it should do it. In fact, I see it
as an error not doing it. Does not 'autosync' means: do all the pushes
and pulls necessary to keep local repository always syncronized with
remote
On 10/9/2014 13:43, Richard Hipp wrote:
I wonder if we should auto-pull before merge the same as we do before
update?
Isn't a more appropriate comparison to
fossil update $VERSION_NOT_YET_SYNCHED_TO_MY_LOCAL_REPO_COPY
?
That is to say, if update also had a -r option, wouldn't
My early experience with Fossil and autosync ON was not intuitive and I
may have experienced Dr Hipp's scenario. In my case, slow remote repo's. I
decided on a granular approach automated by my own code.
autosync OFF
Start{
fossil status ...
...review uncommitted local changes and fossil commit
On Fri, Oct 10, 2014 at 10:45 AM, Andy Bradford amb-fos...@bradfords.org
wrote:
Thus said =?UTF-8?Q?Ramon_Rib=C3=B3?= on Fri, 10 Oct 2014 10:01:47 +0200:
If autosync is activated, of course it should do it. In fact, I see it
as an error not doing it. Does not 'autosync' means: do all the
...
I've been mildly bitten by this behavior before. When merging from a
branch a warning that you haven't sync'd would be a nice to have.
Autosync prior to merge would work for me but the warning would be a
decent alternative.
+1 for the warning message...
...
+2 on the warning
On 10/10/2014 09:42, Warren Young wrote:
That is to say, if update also had a -r option, wouldn't ?VERSION? be
its argument?
Sorry, that's confusing. I see that update and merge both use ?VERSION?
instead of -r.
I also see that fossil update ?VERSION? auto-syncs before updating.
(When I
On 10/10/2014 9:50 AM, Warren Young wrote:
Since fossil merge ?VERSION? has the same command form, I
would expect it to auto-sync as well, if that option is enabled.
Personally, I wouldn't expect that at all. The fossil merge command
edits the currently open workspace based on
On Fri, Oct 10, 2014 at 10:10 PM, Ross Berteig r...@cheshireeng.com wrote:
Personally, I wouldn't expect that at all. The fossil merge command
edits the currently open workspace based ...
+1
The fossil update command on the other hand is not about making edits to
the workspace that need
I just did a fossil merge $BRANCH for some changes that a colleague
checked in, and was puzzled to not see much change in the code. After I
while, I finally figured out that I should have do fossil pull first. :-\
I wonder if we should auto-pull before merge the same as we do before
update?
--
On Thu, Oct 9, 2014 at 10:18 PM, j. v. d. hoff veedeeh...@googlemail.com
wrote:
my first reaction would be: no. I feel that when issuing `merge' it
should
That's also my gut reaction. Optionally, sure, but if so then off by
default.
--
- stephan beal
I've been mildly bitten by this behavior before. When merging from a branch
a warning that you haven't sync'd would be a nice to have. Autosync prior
to merge would work for me but the warning would be a decent alternative.
On Thu, Oct 9, 2014 at 12:43 PM, Richard Hipp d...@sqlite.org wrote:
I
25 matches
Mail list logo
