On Wed, Aug 21, 2013 at 8:37 AM, Matt Welland wrote:
> Regarding stable numbered tags. How about a script or added feature that
> scans the timeline and tags every node in a systematic way similar to what
> people might expect from Subversion or similar tools?
>
> v1.1 -> v1.2 -> v1.3
> \.-
On Thu, 22 Aug 2013 00:55:56 +0200, Matt Welland
wrote:
On Wed, Aug 21, 2013 at 2:29 PM, j. van den hoff
wrote:
On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal
wrote:
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen
>wrote:
The fossil rebuild logic uses a two pass algorithm. I am not q
On Wed, Aug 21, 2013 at 2:29 PM, j. van den hoff
wrote:
> On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal
> wrote:
>
> On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen > >wrote:
>>
>> The fossil rebuild logic uses a two pass algorithm. I am not quite sure
>>> why this is necessary, it could have
On 21 Aug 2013 23:22, "j. van den hoff" wrote:
>
> On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen
wrote:
>
>> On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
>> wrote:
>>
>>> On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen
>>> wrote:
>>>
>>> To make this less of an academic discussion and t
On Wed, Aug 21, 2013 at 11:22 PM, j. van den hoff wrote:
> understood. what I do not get is (apart from that's it probably not part
> of the current machinery) why it
> would be complicated (for the people in the know) to just log the checkins
> and count them while they arrive in the db
i've b
On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal
wrote:
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen
wrote:
The fossil rebuild logic uses a two pass algorithm. I am not quite sure
why this is necessary, it could have something to do with delta
manifests.
At http://mpcjanssen.nl/fossi
On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen
wrote:
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
wrote:
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen
wrote:
To make this less of an academic discussion and to just be able to play
very good point (despite being myself in aca
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen wrote:
> The fossil rebuild logic uses a two pass algorithm. I am not quite sure
> why this is necessary, it could have something to do with delta manifests.
> At http://mpcjanssen.nl/fossil/fossil/timeline?r=revlist I have changed
> this to a single
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
wrote:
> On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen
> wrote:
>
> To make this less of an academic discussion and to just be able to play
>>
>
> very good point (despite being myself in academia ...) and thanks a lot
> for sharing this.
>
>
>
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen
wrote:
To make this less of an academic discussion and to just be able to play
very good point (despite being myself in academia ...) and thanks a lot
for sharing this.
around with it,
http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:
On Wed, Aug 21, 2013 at 7:36 PM, Stephan Beal wrote:
> On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen wrote:
>
>> Currently the revision numbers are reflecting the fossil rebuild
>> algorithm so they count down from leaves which is a bit odd, but that can
>> probably be improved.
>>
>
> Coincident
On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen wrote:
> Currently the revision numbers are reflecting the fossil rebuild algorithm
> so they count down from leaves which is a bit odd, but that can probably be
> improved.
>
Coincidentally, this block _might_ affect you in a negative way:
http://m
To make this less of an academic discussion and to just be able to play
around with it,
http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlist&to=r:5746&sbs=1 has
an implementation of having repository local rev numbers for commits only.
After updating fossil you'll need to do a fossil rebuild
On Wed, Aug 21, 2013 at 8:37 AM, Matt Welland wrote:
> Regarding stable numbered tags. How about a script or added feature that
> scans the timeline and tags every node in a systematic way similar to what
> people might expect from Subversion or similar tools?
>
> v1.1 -> v1.2 -> v1.3
> \.-
I'll reply to this mail again, since it is essentially the only one
exactly addressing my point:
-- I agree that any non-local use of revnums is doomed to failure (with
checkins tickets or whatever).
-- we don't need some new `svn' like naming scheme of revisions instead of
the hashes (1.
On Wed, Aug 21, 2013 at 5:43 PM, Stephan Beal wrote:
> Side-note...
>
> the library interface will allow clients to add this sort of supplemental
> metadata/functionality, and will eventually provide enough
>
Side-note #2/shameless plug: the library effort is coming along nicely but
more collabo
On Wed, Aug 21, 2013 at 5:37 PM, j. van den hoff
wrote:
> thanks for this clarification. so, while you don't share my view that the
> sequential revnums (yes: exactly the same thing as in mercurial) are a good
> thing, I still do (from some years of usage of mercurial). I've tried to
> argue for t
On Wed, 21 Aug 2013 17:10:59 +0200, Stephan Beal
wrote:
On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal
wrote:
> DVCSs cannot, by their very nature, portably support sequential
numbers.
> This topic has been beaten to death by brains m
On Wed, 21 Aug 2013 17:09:52 +0200, Richard Hipp wrote:
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal
wrote:
> DVCSs cannot, by their very nature, portably support sequential
numbers.
> This topic has been beaten to death by brains mu
Regarding stable numbered tags. How about a script or added feature that
scans the timeline and tags every node in a systematic way similar to what
people might expect from Subversion or similar tools?
v1.1 -> v1.2 -> v1.3
\.-> v1.1.1
If the script worked incrementally and was run centrally
For most of the use cases discussed here I think we don't need repository
local unique numbers a la mercurial. As far as I can see a more flexible
VERSION [1] format (although the git way is probably overkill) seems to be
enough. It would be useful for example to be able to say:
fossil diff -r -2
On Wed, Aug 21, 2013 at 5:26 PM, Mark Janssen wrote:
> One reason which would make my life easier is when dealing with tickets,
> it is much easier to discuss bug 12 (in blessed repo X) instead of ticket
> uuid [some 8+ digit number]. When I work with tickets on github I know the
> bug ids of tic
On Wed, Aug 21, 2013 at 11:26 AM, Mark Janssen wrote:
>
> One reason which would make my life easier is when dealing with tickets,
> it is much easier to discuss bug 12 (in blessed repo X) instead of ticket
> uuid [some 8+ digit number]. When I work with tickets on github I know the
> bug ids of t
On Wed, Aug 21, 2013 at 5:09 PM, Richard Hipp wrote:
> On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson wrote:
>
>> On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal
>> wrote:
>> > DVCSs cannot, by their very nature, portably support sequential numbers.
>> > This topic has been beaten to death by bra
On Wed, Aug 21, 2013 at 5:10 PM, Stephan Beal wrote:
> such problems if they cannot be reproduced easily. i could see it being
> halfway reliable for diffs, but not commits, because any change to the
> filesystem or repo can change the list of files used by the commit command.
>
A silly but very
last mail in these matters since it is in danger of deteriorating into
just another flame.
On Wed, 21 Aug 2013 16:36:58 +0200, Stephan Beal
wrote:
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
wrote:
with due respect, that's too dogmatic for my taste. and it's also a
question what yo
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson wrote:
> On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal
> wrote:
> > DVCSs cannot, by their very nature, portably support sequential numbers.
> > This topic has been beaten to death by brains much larger than mine.
>
> Joerg's original proposal (in a
On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson wrote:
> On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal
> wrote:
> > DVCSs cannot, by their very nature, portably support sequential numbers.
> > This topic has been beaten to death by brains much larger than mine.
>
> Joerg's original proposal (in a
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal wrote:
> DVCSs cannot, by their very nature, portably support sequential numbers.
> This topic has been beaten to death by brains much larger than mine.
Joerg's original proposal (in a previous thread) was to support
_local_ sequential revision number
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
wrote:
> with due respect, that's too dogmatic for my taste. and it's also a
> question what you decide to include
>
Domagtic, it is. It is a fact of software development, in particular
long-lived software, that once an internal implementation deta
unintentionally replied only to stephan, but this should stay on th list,
I'd say, so:
On Wed, 21 Aug 2013 16:08:16 +0200, Stephan Beal
wrote:
On Wed, Aug 21, 2013 at 3:25 PM, j. van den hoff
wrote:
"philosophical" issues aside:
does that mean that with the current implementation (and prob
On Wed, Aug 21, 2013 at 1:50 PM, Richard Hipp wrote:
> Furthermore, this feature is for debugging use only and should not get in
> the way of end users. Perhaps it should be changed such that the record ID
> is only used if the input begins with "rid:"?
>
Just checked in:
stephan@tiny:~/cvs/fo
On Wed, 21 Aug 2013 13:25:50 +0200, Stephan Beal
wrote:
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff
wrote:
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal
wrote:0.
intentionally undocumented or did nobody manage to add it to the
manpages?
Intentional - see the comment line at t
On Wed, Aug 21, 2013 at 1:48 PM, Richard Hipp wrote:
> In fact, I thought that was the way it worked, though I haven't looked at
> the code lately and I might have missed something.
>
That is how it works - it's a last-ditch effort before returning 0.
Adding an rid: prefix to it is a good idea -
On Wed, Aug 21, 2013 at 7:48 AM, Richard Hipp wrote:
> On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal wrote:
>
>>
>> On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff <
>> veedeeh...@googlemail.com> wrote:
>>
>>> On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal
>>> wrote:0.
>>> intentionally undo
On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal wrote:
>
> On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff <
> veedeeh...@googlemail.com> wrote:
>
>> On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal
>> wrote:0.
>> intentionally undocumented or did nobody manage to add it to the
>> manpages?
>>
>
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff
wrote:
> On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal
> wrote:0.
> intentionally undocumented or did nobody manage to add it to the manpages?
>
Intentional - see the comment line at the start of that block.
> 1.
> I don't hope this happens w
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal
wrote:
On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff
wrote:
hopefully not a stupid question: what's going on here? can someone
confirm
this? there is no checkin with a SHA1 hash starts with 5731 (or contain
it)
it seems.
An undo
On Wed, Aug 21, 2013 at 12:58 PM, Stephan Beal wrote:
>
> On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff <
> veedeeh...@googlemail.com> wrote:
>
>> hopefully not a stupid question: what's going on here? can someone
>> confirm this? there is no checkin with a SHA1 hash starts with 5731 (or
>> co
On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff wrote:
> hopefully not a stupid question: what's going on here? can someone confirm
> this? there is no checkin with a SHA1 hash starts with 5731 (or contain it)
> it seems.
>
An undocumented feature: artifact symbols which look like integers are
hi,
I have stumbled over the following observation when performing these
action within a checkout of of `fossil' itself:
fossil timeline -v -n 10 | grep 5731 ## --> no hit
fossil diff -r 5731 ## lots of output (related to which revision???)
hopefully not a stupid question: what's going
41 matches
Mail list logo
