On Sat, Oct 11, 2014 at 5:36 AM, David Mason wrote:
> Seems a bit weird, but OK... so how do I find out which of the
> artifacts was a manifest... and does this mean I can't have a file in
> the repo called "manifest" ?
>
Section 1.0 of the link you quoted hints at the answer:
"Any artifact in
On 10 October 2014 16:55, Ron W wrote:
> Every commit will have a manifest. In the manifest, the "U card" will
> identify the user making the commit. See
> http://fossil-scm.org/index.html/doc/tip/www/fileformat.wiki
Thanks for the pointer, and I read the related pages on the sync
protocol, etc.
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 Fri, Oct 10, 2014 at 9:27 AM, David Mason wrote:
> So the student would do:
> fossil clone -A student1 ssh://x...@re.mote/student1.fossil
> srepo.fossil
>
> so they would not be able to represent
> themselves as the prof or the TA. Any checkins with other user would
> be ignored.
>
If yo
On Fri, Oct 10, 2014 at 2:42 PM, David Mason 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 required students
to
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 October 2014 10:18, Ron W wrote:
> On Fri, Oct 10, 2014 at 9:27 AM, David Mason 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:
>
...
manifest = formal checkout record.
then generate some more questions, such as 'where is the signature relative
to the 'manifest' (or does it maybe make a pkcs7 out of the plaintext
manifest), and how do I verify the signature', 'what is a 'clearsign'', etc.
The signature gets wrapper a
On Fri, Oct 10, 2014 at 6:05 PM, dave 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 to the 'manifes
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 12:05 PM, dave 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 some more
...
> > 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
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 c
-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 wrote:
Q: what does it do, and how is it used, when would one want that in their
workflow or not?
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 Fri, Oct 10, 2014 at 11:32 AM, dave 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 if I have
> ov
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
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 wi
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:27 AM, David Mason 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 userid URL"
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
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 (thank
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
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 th
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
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 wrote:
> On Fri, Oct 10, 2014 at 1:56 PM, Graeme Pietersz
> wrote:
>
> > Thanks for the explanation, further questions below if I can stretch
> > your pat
On Fri, Oct 10, 2014 at 1:56 PM, Graeme Pietersz
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 production are o
On Fri, Oct 10, 2014 at 11:01 AM, Graeme Pietersz
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 both
> have the
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
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 file
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
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)
artifact
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
38 matches
Mail list logo
