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
Hello,
just wonder what impact on Fossil is the news that recent Sqlite3 is
50% faster than 3.7.17?
In regard to it, I also wonder what is your estimation of Fossil's
suitability to handle the project with the following stats:
$ fossil dbstat
repository-size: 660814848 bytes (660.8MB)
I have another idea. Fossil diff and commit appear to ignore
file timestamps, so I think this will work:
1) Copy .fslckout from test to production.
2) Update the path to the repo (which is probably the same as they both
have the same relative path to the repo).
3) Run fossil diff to see which
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]
On Fri, Oct 10, 2014 at 11:01 AM, Graeme Pietersz gra...@pietersz.net
wrote:
I have another idea. Fossil diff and commit appear to ignore
file timestamps, so I think this will work:
1) Copy .fslckout from test to production.
2) Update the path to the repo (which is probably the same as they
On Fri, Oct 10, 2014 at 1:56 PM, Graeme Pietersz gra...@pietersz.net
wrote:
Thanks for the explanation, further questions below if I can stretch
your patience a bit!
Not stretching at all, except that i'm trying to stretch my imagination as
to how fossil might be used to do this ;).
Test and
Thank you Stephan! I have a solution and I have a better understanding
of Fossil as well :)
On Fri, 10 Oct 2014 13:59:55 +0200
Stephan Beal sgb...@googlemail.com wrote:
On Fri, Oct 10, 2014 at 1:56 PM, Graeme Pietersz gra...@pietersz.net
wrote:
Thanks for the explanation, further questions
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
Some may remember that about a year ago I was trying to get fossil set
up for students in a course. I didn't get it set up then (too much
going on, time pressure, etc.) but I'm doing it now.
I am using the ssh-with-keys-and-forced-commands setup that Andy set
up (thanks!) but one of the things
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
Oops... sent prematurely..
Some may remember that about a year ago I was trying to get fossil set
up for students in a course. I didn't get it set up then (too much
going on, time pressure, etc.) but I'm doing it now.
I am using the ssh-with-keys-and-forced-commands setup that Andy set
up
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
On Fri, Oct 10, 2014 at 9:27 AM, David Mason dma...@ryerson.ca wrote:
So the student would do:
fossil clone -A student1 ssh://x...@re.mote/student1.fossil
srepo.fossil
Using a wrapper around Fossil, this form of the clone command could be
automated:
fsl clone URL becomes fossil close -A
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
Q: what does it do, and how is it used, when would one want that in their
workflow or not?
I'm thoroughly versed in crypto in general, but I don't understand it's use
in the fossil workflow. Any feedback is appreciated, and if I have
overlooked some existing doc, by all means direct me to it
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
On Fri, Oct 10, 2014 at 11:32 AM, dave d...@ziggurat29.com wrote:
Q: what does it do, and how is it used, when would one want that in
their workflow or not?
I'm thoroughly versed in crypto in general, but I don't understand it's
use in the fossil workflow. Any feedback is appreciated, and
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
-Original Message-
From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp
... Fri, Oct 10, 2014 at 11:32 AM, dave d...@ziggurat29.com wrote:
Q: what does it do, and how is it used, when would one want that in
Fossil sub-commands sometimes take -r VERSION options and other times
take optional ?VERSION? arguments. This is confusing. I propose that
this be fixed in three stages:
1. Add -r options to every command that takes ?VERSION? options.
2. Change all the docs to show only -r, but allow 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 Fri, Oct 10, 2014 at 12:05 PM, dave d...@ziggurat29.com wrote:
Important artifacts, such as the manifest that describes a check-in can
be PGP clear-signed
...
Thanks; OK, well I guess I need to do some more reading so I can know what
a 'manifest' is in this context, and then generate
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 Fri, Oct 10, 2014 at 6:05 PM, dave d...@ziggurat29.com wrote:
Thanks; OK, well I guess I need to do some more reading so I can know
what a 'manifest' is in this context, and
manifest = formal checkout record.
then generate some more questions, such as 'where is the signature
relative
On 10 October 2014 10:18, Ron W ronw.m...@gmail.com wrote:
On Fri, Oct 10, 2014 at 9:27 AM, David Mason dma...@ryerson.ca wrote:
So the student would do:
fossil clone -A student1 ssh://x...@re.mote/student1.fossil
srepo.fossil
Using a wrapper around Fossil, this form of the clone
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 2:42 PM, David Mason dma...@ryerson.ca wrote:
Yes, but the client side is on their own laptop or whatever, so no
opportunity to wrap.
So, you aren't providing a zip file of standardized tools for the class?
That's what has happened for every class I've taken that
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
33 matches
Mail list logo
