Re: [fossil-users] auto-sync before merge?
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 the branch as it is currently in your private database. The please sync crowd sees the merge as being from the latest on the tip whether I have it currently or not. Neither world view is intrinsically right but I do personally feel that if you intend to get a specific node (the don't sync crowd) then specify the node. To be consistent with the fossil closely-coupled model I feel that where possible fossil should autosync. For most of us bandwidth is not an issue and sync can always be turned off. Auto sync before merge and after tagging would have saved me a few support calls from confused users over the past few years :) I agree with this view. People that needs control to witch exact commit they want to merge from can either disconnect autosync or specify the exact commit id. I would add that, additionally to autosync in commits and updates, it would be nice to sync during merges, tag changes and ticket changes. RR 2014-10-13 3:58 GMT+02:00 Matt Welland estifo...@gmail.com: 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 command on the other hand is not about making edits to the workspace that need to be ... +1 The autosync mechanism is fundamentally about keeping your repository synchronized with a remote repository, and has no effect on any open workspaces. +1 IMHO, the principle of least surprise should apply, and argues lightly against autosync on merge and is somewhat ambivalent about autosync on update. i like autosync on update - it's saved me from forks countless times. Here is a little more detail on the merge scenario that has confused me and others. 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 the branch as it is currently in your private database. The please sync crowd sees the merge as being from the latest on the tip whether I have it currently or not. Neither world view is intrinsically right but I do personally feel that if you intend to get a specific node (the don't sync crowd) then specify the node. To be consistent with the fossil closely-coupled model I feel that where possible fossil should autosync. For most of us bandwidth is not an issue and sync can always be turned off. Auto sync before merge and after tagging would have saved me a few support calls from confused users over the past few years :) Just my $0.02. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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
*is*
ambiguity. The don't sync crowd sees the merge as applying to the tip
of
the branch as it is currently in your private database. The please
sync
crowd sees the merge as being from the latest on the tip whether I have
it
currently or not. Neither world view is intrinsically right but I do
personally feel that if you intend to get a specific node (the don't
sync
crowd) then specify the node. To be consistent with the fossil
closely-coupled model I feel that where possible fossil should
autosync. For
most of us bandwidth is not an issue and sync can always be turned off.
Auto
sync before merge and after tagging would have saved me a few support
calls
from confused users over the past few years :)
I agree with this view. People that needs control to witch exact
commit they want to merge from can either disconnect autosync or
which sure is more of a hassle than typing `fossil pull' would be for
people arguing for a change when keeping the present behaviour.
and I would insist that forgetting to issue `pull' in the present
situation does lead to less havoc/confusion than would be the case
if `merge' were issued (forgetting to specify the hash) after changing the
present bevhaviour -- and that's what definitely is going to
happen sooner or later just as now people forget to `pull' prior to
`merge' by and then (without causing real grief I'd say).
specify the exact commit id.
('most) nobody wants to switch off autosync. it's to important/useful in
the `ci/up' context.
I realize -- as matt -- that there are two attitudes/use cases involved
here. I also agree that both can be justified. question remains
whether this justifies the contemplated change in behaviour (the more so
since immediately many additional complications seem to pop up).
in any case, by all means, keep the present behaviour as default...
I would add that, additionally to autosync in commits and updates, it
would be nice to sync during merges, tag changes and ticket changes.
RR
2014-10-13 3:58 GMT+02:00 Matt Welland estifo...@gmail.com:
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 command on the other hand is not about making
edits
to the workspace that need to be ...
+1
The autosync mechanism is fundamentally about keeping your repository
synchronized with a remote repository, and has no effect on any open
workspaces.
+1
IMHO, the principle of least surprise should apply, and argues lightly
against autosync on merge and is somewhat ambivalent about autosync on
update.
i like autosync on update - it's saved me from forks countless times.
Here is a little more detail on the merge scenario that has confused me
and
others.
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
the branch as it is currently in your private database. The please
sync
crowd sees the merge as being from the latest on the tip whether I have
it
currently or not. Neither world view is intrinsically right but I do
personally feel that if you intend to get a specific node (the don't
sync
crowd) then specify the node. To be consistent with the fossil
closely-coupled model I feel that where possible fossil should
autosync. For
most of us bandwidth is not an issue and sync can always be turned off.
Auto
sync before merge and after tagging would have saved me a few support
calls
from confused users over the past few years :)
Just my $0.02.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct
of
those who insist on a perfect world, freedom will have to do. --
Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in
the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users
Re: [fossil-users] auto-sync before merge?
[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 not an issue and sync can always be turned off.
Auto sync before merge and after tagging would have saved me a few support
calls from confused users over the past few years :)
I agree with this view. People that needs control to witch exact
commit they want to merge from can either disconnect autosync or
which sure is more of a hassle than typing `fossil pull' would be for
people arguing for a change when keeping the present behaviour.
and I would insist that forgetting to issue `pull' in the present
situation does lead to less havoc/confusion than would be the case
if `merge' were issued (forgetting to specify the hash) after changing the
present bevhaviour -- and that's what definitely is going to
happen sooner or later just as now people forget to `pull' prior to
`merge' by and then (without causing real grief I'd say).
+1
specify the exact commit id.
('most) nobody wants to switch off autosync. it's to important/useful
in the `ci/up' context.
I realize -- as matt -- that there are two attitudes/use cases involved
here. I also agree that both can be justified. question remains
whether this justifies the contemplated change in behaviour (the more so
since immediately many additional complications seem to pop up).
in any case, by all means, keep the present behaviour as default...
+1
--
Regards,
Kees Nuyt
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 the main repo, an auto-pull before merge would make sense. But when bringing in contributor changes, the potential for unpleasant surprises is much greater. Also, remember the rule of commit early; commit often. This is because it's easier to find and fix issues when difference from one commit to the next is small. this applies to merges as well. Yes, I know it is tedious. And I will admit there are times when having a code monkey around to do the tedious stuff would be nice. But then I have to make sure the tedious stuff was being done correctly. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 command on the other hand is not about making edits to the workspace that need to be ... +1 The autosync mechanism is fundamentally about keeping your repository synchronized with a remote repository, and has no effect on any open workspaces. +1 IMHO, the principle of least surprise should apply, and argues lightly against autosync on merge and is somewhat ambivalent about autosync on update. i like autosync on update - it's saved me from forks countless times. Here is a little more detail on the merge scenario that has confused me and others. 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 the branch as it is currently in your private database. The please sync crowd sees the merge as being from the latest on the tip whether I have it currently or not. Neither world view is intrinsically right but I do personally feel that if you intend to get a specific node (the don't sync crowd) then specify the node. To be consistent with the fossil closely-coupled model I feel that where possible fossil should autosync. For most of us bandwidth is not an issue and sync can always be turned off. Auto sync before merge and after tagging would have saved me a few support calls from confused users over the past few years :) Just my $0.02. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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: 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 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? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 repository? Historically yes, but not in the context of a merge. Merging has, in terms of workflow, always assumed offline mode, performing no explicit syncing. Whether or not the historical meaning of autosync should be expanded to cover other commands is debatable, and i'd argue for a new option either specific to merge or generically for use with commands which optionally want to pull automatically but not push. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 pulls necessary to keep local repository always syncronized with remote repository? Historically yes, but not in the context of a merge. Merging has, in terms of workflow, always assumed offline mode, performing no explicit syncing. Whether or not the historical meaning of autosync should be expanded to cover other commands is debatable, and i'd argue for a new option either specific to merge or generically for use with commands which optionally want to pull automatically but not push. Provision of an option seems like the best approach. That said, I do worry that these sorts of knobs increase the overall complexity of fossil (both from a user and implementation perspective). Joerg's point, it would be somewhat more puzzling/annoying if a merge includes possibly not yet known/visible stuff than the other way round (forgetting to pull prior to merge) seems apt. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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-sync before merge? 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 new opportunity to have more bugs in the less used branch of the option. I do not completely agree with this idea, as sometimes options are useful to give opportunity to use the same program with different workflows. However, I consider more of a success of a program every option avoided than every option added. RR 2014-10-10 10:08 GMT+02:00 Stephan Beal sgb...@googlemail.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 repository? Historically yes, but not in the context of a merge. Merging has, in terms of workflow, always assumed offline mode, performing no explicit syncing. Whether or not the historical meaning of autosync should be expanded to cover other commands is debatable, and i'd argue for a new option either specific to merge or generically for use with commands which optionally want to pull automatically but not push. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 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? 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... But I guess in order to have a meaningful warning message, the merge command will have to do a kind of fake pull to know if the local repo need a pull or not. And in that case, we could have different warning message depending on the situation. - When remote repo have new content to pull - When remote repo is not accessible, so we don't know if we have latest changes. - may be something else ... 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 ? Any tough ? -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 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 an intervening manual pull or commit, the results are identical, and auto-pull removes that guaranty. If we need it, let's please make it an option. i sympathize with options adding complexity, but we've got lots of precedence for them in fossil. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 command if the user want to pull before merge ? 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 an intervening manual pull or commit, the results are identical, and auto-pull removes that guaranty. If we need it, let's please make it an option. i sympathize with options adding complexity, but we've got lots of precedence for them in fossil. I really would think this to be mostly a non-issue (it seemingly never came up before drh now was contemplating it himself?). and while another option is OK (as long as it is OFF by default!) I don't believe it would constitute an improvement. it would add one more to the already not-so-few options and the signal-to-noise ratio (i.e. the ratio of really vital/relevant/helpful options to the 'maybe-sometimes-nice-to-have-too' options would be decreased in my view, making `fossil settings' output more verbose etc. 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 some sort of artificial intelligence instead of just operating on the given state of the (local) repository. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
+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 `merge' would develop some sort of artificial intelligence instead of just operating on the given state of the (local) repository. ../Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 in a row, without an intervening manual pull or commit, the results are identical, and auto-pull removes that guaranty. My first experience with a DVCS, years ago, specifically Git, the recommended sequence of steps, in the Git tutorials, was pull, review then merge. And yes, this sometimes meant I did more than 1 pull/review/merge back-to-back, but this seems the sanest way to bring in changes, even from core project members. (And, the man thing I still like about Git is that when I do pull, the contributor's trunk appears in my repo as username-main, rather than directly updating my trunk. Yes, I know that requiring contributors to do dev on branches gets around this, but once in a while, even core devs will accidentally commit to trunk.) If we need it, let's please make it an option. i sympathize with options adding complexity, but we've got lots of precedence for them in fossil. If this is included, it should be an option and should default to off. A review should be done prior to the merge - even if the merge is done using an interactive tool. An auto-pull before a merge makes the reviewing harder. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 repository? I believe the original intent for autosync was as a fork avoidance mechanism. Merge does not fork. I for one don't think it necessary to have autosync with merge, but can see why some would want it---hopefully as an option that is disabled by default. Andy -- TAI64 timestamp: 40005437f12f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 ?VERSION? be its argument? A counterargument in favor of auto-pull before merge is that merge normally works on things at the tip of their branches, so it makes sense to go grab all the tips first. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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
fossil pull ...
fossil update ...
fossil leave ...
...review any leaves and fossil merge
fossil commit ...
fossil push ...
Stop}
Can someone explain their autosync ON flow and why adding more auto to it
would be considered contradictory?
Start{
fossil status ...
...review uncommitted local changes and fossil commit
//is this handled by autosync? fossil pull ...
//is this handled by autosync? fossil update ...
//is this handled by autosync? fossil leave ...
//is this handled by autosync? ...review any leaves and fossil merge
fossil commit ...
fossil push ...
Stop}
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 pushes
and pulls necessary to keep local repository always syncronized with
remote repository?
I believe the original intent for autosync was as a fork avoidance
mechanism. Merge does not fork.
I for one don't think it necessary to have autosync with merge, but can
see why some would want it---hopefully as an option that is disabled by
default.
Andy
--
TAI64 timestamp: 40005437f12f
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 pushes and pulls necessary to keep local repository always syncronized with remote repository? I believe the original intent for autosync was as a fork avoidance mechanism. Merge does not fork. I for one don't think it necessary to have autosync with merge, but can see why some would want it---hopefully as an option that is disabled by default. Given that the end result of merge is not auto-committed (and I would never want it auto-committed), it's effect is limited to the check out, not even the local repo. So, elaborating on the sub-workflow I mentioned earlier, I pull, review, merge, build then commit. (Actually, the commit is part of every build I do. the final 2 steps of my build process (1) commit the changes, then (2) update the software identification structure in the executable with the commit ID. That way, whatever every executable someone is using, we can reliably identify the set of sources used to create it.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
... 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 message; I can see the utility in it. Please don't make auto-sync before merge the default behavior. At best, make it an option to cause it to happen. On active repos, particularly those with feature branches, there will often be activity down-line that I have not reviewed, and do not want to pull in, and do not want to interrupt my commit activities to be forced to review them. (Nor do I want to cherry-pick, because that is at a single change set, and does not pick up the things before to common ancestor. Though I guess if I were to merge from the relevant checkin id, rather than the symbolic name, I can achieve the same effect). -dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 posted the previous message, I assumed that only happened if you didn't give a ?VERSION? argument.) Since fossil merge ?VERSION? has the same command form, I would expect it to auto-sync as well, if that option is enabled. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 differences between the current revision and some other named revision. It has no effect on your repository, and nothing happens that cannot be either reverted or fixed by further editing until you actually check in the changes. The only bit of magic that you cannot create without the fossil merge command itself is the marker in the subsequent checkin's manifest that identifies the source of the merge. The fossil update command on the other hand is not about making edits to the workspace that need to be committed. It is about associating the open workspace with some specific revision. When that revision is the tip of any branch (including the implicit trunk), it is a completely reasonable expectation that you would land on the actual tip of that branch. The autosync mechanism is fundamentally about keeping your repository synchronized with a remote repository, and has no effect on any open workspaces. IMHO, the principle of least surprise should apply, and argues lightly against autosync on merge and is somewhat ambivalent about autosync on update. In practice, experience with larger teams has indicated that autosync on update reduces unexpected forking. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 to be ... +1 The autosync mechanism is fundamentally about keeping your repository synchronized with a remote repository, and has no effect on any open workspaces. +1 IMHO, the principle of least surprise should apply, and argues lightly against autosync on merge and is somewhat ambivalent about autosync on update. i like autosync on update - it's saved me from forks countless times. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] auto-sync before merge?
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 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? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
