On Sun, Oct 12, 2014 at 9:58 PM, Matt Welland 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 the main repo, an
[Default] On Mon, 13 Oct 2014 10:29:36 +0200, "j. v. d. hoff"
wrote:
> On Mon, 13 Oct 2014 10:12:02 +0200,
> Ramon Ribó wrote:
>
>> On Sun, 12 Oct 2014 18:58:25 -0700,
>> Matt Welland wrote:
>>>
>>> []
>>> autosync. For
>>> most of us bandwidth is not an issue and sync can always be turned
On Mon, 13 Oct 2014 10:12:02 +0200, Ramon Ribó
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
*is*
ambiguity. Th
> 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 t
On Fri, Oct 10, 2014 at 8:01 PM, Stephan Beal wrote:
> On Fri, Oct 10, 2014 at 10:10 PM, Ross Berteig
> 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
On Fri, Oct 10, 2014 at 10:10 PM, Ross Berteig 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 to be ...
+
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 differe
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
...
> > 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
On Fri, Oct 10, 2014 at 10:45 AM, Andy Bradford
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 pushes
> > and pulls
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 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 ?VE
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
> rem
On Fri, Oct 10, 2014 at 9:23 AM, Stephan Beal 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 in a row, without
+1
On 10 October 2014 09:38, j. v. d. hoff 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 `merge'
> would develop
On Fri, 10 Oct 2014 15:23:31 +0200, Stephan Beal
wrote:
On Fri, Oct 10, 2014 at 3:14 PM, Martin Gagnon 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 befor
On Fri, Oct 10, 2014 at 3:14 PM, Martin Gagnon 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 thing to have
On Thu, Oct 09, 2014 at 03:04:31PM -0700, Matt Welland wrote:
> On Thu, Oct 9, 2014 at 12:43 PM, Richard Hipp 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 finally
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]
Please, do not add a new option.
I read in an interesting article about software development that every
new option in a program is a failure of the designer, who has been
unable to take a decision. Every new option represents a more
complicated manual, a sense of complexity of the product and a ne
On Fri, Oct 10, 2014 at 9:08 AM, Stephan Beal wrote:
> On Fri, Oct 10, 2014 at 10:01 AM, Ramon Ribó 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 re
On Fri, Oct 10, 2014 at 10:01 AM, Ramon Ribó 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 repository?
>
Hist
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 :
> I've been mildly bitt
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 wrote:
> I just did a "fos
On Thu, Oct 9, 2014 at 10:18 PM, j. v. d. hoff
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
http://wanderinghorse.net/home/stephan/
http://gplus.to/s
On Thu, 09 Oct 2014 21:43:43 +0200, Richard Hipp 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 finally figured out that I should have do "fossil pull" first.
:-\
I wonder if we
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
"updat
27 matches
Mail list logo
