On Wed, Aug 21, 2013 at 8:37 AM, Matt Welland estifo...@gmail.com 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 -
On Thu, 22 Aug 2013 00:55:56 +0200, Matt Welland estifo...@gmail.com
wrote:
On Wed, Aug 21, 2013 at 2:29 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen
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
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 contain it)
it seems.
An undocumented feature: artifact symbols which
On Wed, Aug 21, 2013 at 12:58 PM, Stephan Beal sgb...@googlemail.comwrote:
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
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com
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
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com
wrote:0.
intentionally undocumented or did nobody manage to add it to the manpages?
Intentional - see the comment line at the start of that
On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal sgb...@googlemail.com 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 sgb...@googlemail.com
wrote:0.
intentionally undocumented or did nobody manage to
On Wed, Aug 21, 2013 at 7:48 AM, Richard Hipp d...@sqlite.org wrote:
On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal sgb...@googlemail.comwrote:
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
On Wed, Aug 21, 2013 at 1:48 PM, Richard Hipp d...@sqlite.org 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
On Wed, 21 Aug 2013 13:25:50 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com
wrote:0.
intentionally undocumented or did nobody manage to
On Wed, Aug 21, 2013 at 1:50 PM, Richard Hipp d...@sqlite.org 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:
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 sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 3:25 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
philosophical issues aside:
does that mean
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
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
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com 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_
On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential numbers.
This topic has been beaten to death by brains much larger than mine.
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential numbers.
This topic has been beaten to death by brains much larger than mine.
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 sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
with due respect, that's too dogmatic
On Wed, Aug 21, 2013 at 5:10 PM, Stephan Beal sgb...@googlemail.com 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.
On Wed, Aug 21, 2013 at 5:09 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential numbers.
On Wed, Aug 21, 2013 at 11:26 AM, Mark Janssen mpc.jans...@gmail.comwrote:
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
On Wed, Aug 21, 2013 at 5:26 PM, Mark Janssen mpc.jans...@gmail.com 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
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
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
On Wed, 21 Aug 2013 17:09:52 +0200, Richard Hipp d...@sqlite.org wrote:
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential
numbers.
On Wed, 21 Aug 2013 17:10:59 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential
On Wed, Aug 21, 2013 at 5:37 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
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
On Wed, Aug 21, 2013 at 5:43 PM, Stephan Beal sgb...@googlemail.com 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
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
On Wed, Aug 21, 2013 at 8:37 AM, Matt Welland estifo...@gmail.com 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 -
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:revlistto=r:5746sbs=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 7:31 PM, Mark Janssen mpc.jans...@gmail.com 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
On Wed, Aug 21, 2013 at 7:36 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen mpc.jans...@gmail.comwrote:
Currently the revision numbers are reflecting the fossil rebuild
algorithm so they count down from leaves which is a bit odd, but that can
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com
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,
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com
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
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen mpc.jans...@gmail.comwrote:
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
On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:
To make this less of an academic discussion and to
On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen
mpc.jans...@gmail.comwrote:
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
On Wed, Aug 21, 2013 at 11:22 PM, j. van den hoff veedeeh...@googlemail.com
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
On 21 Aug 2013 23:22, j. van den hoff veedeeh...@googlemail.com wrote:
On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen
On Wed, Aug 21, 2013 at 2:29 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen mpc.jans...@gmail.com
wrote:
The fossil rebuild logic uses a two pass algorithm. I
41 matches
Mail list logo
