Re: [fossil-users] diff after update
If I understand things right, this is a diff against the undo buffer, so I suggest this alternative: fossil diff --undo-buffer BR, Johan El 13/9/2015 5:39, "Lonnie Abelbeck" escribió: > > On Sep 11, 2015, at 7:19 PM, Scott Robison > wrote: > > > On Fri, Sep 11, 2015 at 6:07 PM, Steve Stefanovich wrote: > > Clever, but awkward in my opinion; the first place to look for such a > feature would be under diff command. At least for me, that is. > > > > My vote is for diff --from|--to undo, where 'undo' is a special tag, > same as 'ckout' in different context. I think it fits in such paradigm > nicely. > > > > The person who names branches 'undo' can be perhaps warned in the > command help to use the hash instead. > > > > S. > > > > Here is the stash version of diff: > > fossil stash diff ?STASHID? > > fossil stash gdiff ?STASHID? > > > > Why not do it the same way for undo? It seems to be most in line with > precedent. Perhaps because undo doesn't currently have subcommands, just > options. Still, it would be the most intuitive thing based on existing > practice. > > > > -- > > Scott Robison > > +1 > > Editing the "stash" help added to "undo" would look something like... > > -- snippet -- > > fossil undo diff ?DIFF-OPTIONS? > fossil undo gdiff ?DIFF-OPTIONS? > > Show diffs of the current working checkout and what that > checkout would be if "undo" were applied. > > SUMMARY: > fossil undo > fossil undo [g]diff ?DIFF-OPTIONS? > > -- > Lonnie > > ___ > 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] diff after update
On Sep 11, 2015, at 7:19 PM, Scott Robison wrote: > On Fri, Sep 11, 2015 at 6:07 PM, Steve Stefanovich wrote: > Clever, but awkward in my opinion; the first place to look for such a feature > would be under diff command. At least for me, that is. > > My vote is for diff --from|--to undo, where 'undo' is a special tag, same as > 'ckout' in different context. I think it fits in such paradigm nicely. > > The person who names branches 'undo' can be perhaps warned in the command > help to use the hash instead. > > S. > > Here is the stash version of diff: > fossil stash diff ?STASHID? > fossil stash gdiff ?STASHID? > > Why not do it the same way for undo? It seems to be most in line with > precedent. Perhaps because undo doesn't currently have subcommands, just > options. Still, it would be the most intuitive thing based on existing > practice. > > -- > Scott Robison +1 Editing the "stash" help added to "undo" would look something like... -- snippet -- fossil undo diff ?DIFF-OPTIONS? fossil undo gdiff ?DIFF-OPTIONS? Show diffs of the current working checkout and what that checkout would be if "undo" were applied. SUMMARY: fossil undo fossil undo [g]diff ?DIFF-OPTIONS? -- Lonnie ___ 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] diff after update
On 13 September 2015 at 02:21, Andy Bradford wrote: > Thus said Warren Young on Fri, 11 Sep 2015 18:27:36 -0600: > > > Also, it implies that you're asking Fossil to undo changes, modified > > in some way using diffs. > > Fair enough. I only expressed my opinion about where I thought it fit, > with the intention of avoiding having yet another word or name that > people have to avoid in their repositories. > > I can certainly see how it would be confusing as part of the undo > command. > > The undo command has a -n | --dry-run option. We could add a sub-option of 'diff' : fossil undo -n diff I like that it's related to the --dry-run notion, but it breaks with every other implementation of --dry-run within fossil. So, we would need it nowhere or everywhere. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Cannot set remote-url password when running Fossil non-interactively
Hi, In my application (Fuel) users can set the default remote url for their repositories. The application spawns Fossil with the "remote-url " parameters. It appears however that when urls contain passwords, Fossil does not store the provided password. I think that the problem lies with the way that Fossil handles urls when spawned non-interactively, specifically all password saving is prevented in Fossil's url.c since "isatty(fileno(stdin))" is false when spawned via another application. Perhaps passwords could be explicitly stored when run non-interactively, or some other mechanism could be introduced. Thanks Kostas ___ 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] diff after update
Thus said Warren Young on Fri, 11 Sep 2015 18:27:36 -0600: > Also, it implies that you're asking Fossil to undo changes, modified > in some way using diffs. Fair enough. I only expressed my opinion about where I thought it fit, with the intention of avoiding having yet another word or name that people have to avoid in their repositories. I can certainly see how it would be confusing as part of the undo command. Thanks, Andy -- TAI64 timestamp: 400055f46d34 ___ 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] Multiple Projects in one Repo
On Sat, Sep 12, 2015 at 8:34 AM, Oliver Friedrich < redtalonof+mailingl...@gmail.com> wrote: > > My current solution is to have one repository with an empty initial > check-in tagged as ROOT. Then I do one branch per sub-project based on the > ROOT check-in. > > That way I'm able to keep my code cleanly detached from each another, but > it feels really dirty - cause that's in no way the correct handling of > branches. > > What I really would like to have is to gather multiple such small projects > in one repo file, so instead of having one ROOT check-in, having one ROOT > for each project. I know that would make developing fossil a bit harder, > but I think it would be a great feature and that not I'm the only one who > would use this. > It is already possible to create multiple "initial, empty check-ins" (aka "ROOT", if you really want to do that. However, be default, each one would have it's own "trunk". To avoid confusion, you would need to rename them. What you are doing, a "main branch" for each project, is probably the simplest, cleanest way. (Nested projects are usually most useful for when you have 1 or more shared sub-projects. Not really applicable to your situation.) ___ 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] Multiple Projects in one Repo
On 9/12/15, Oliver Friedrich wrote: > I have bunch of code-samples and abstracted code-problems in > different programming languages and flavours, that I keep as personal > knowledge database. I tend to give each of them its own fossil repository, > but as I mentioned before, sometimes they have just one or two files. > > What would be your approach on my problem? > I keep all of my person notes like this in a single Fossil repository that I call "toolbox.fossil". It does not change that often (my toolbox averages 8 or 9 check-ins per year for the previous 7 years), so it does not really matter that it is a big jumble of one- and two-file projects and code snippets. -- 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
Re: [fossil-users] Multiple Projects in one Repo
If I get your script right, then I would have one fossil repository for
each sub-project and one for the top-project. So with nested repositories
my administration overhead would exceed even the single repository
solution, right?
Johan Kuuse schrieb am Sa., 12. Sep. 2015 um 16:27 Uhr:
> Hi,
>
> After some suggestions in this ML, I chose using nested repositories.
> The "root repository", which I called 'nested', only contains a few files.
> All other repositories are open inside the 'nested' directory, with the
> -nested option.
>
> Here is a script which clones, opens and updates the entire nested
> directory tree (fossul-setuo.sh):
>
> http://kuu.se/fossil/nested.cgi/doc/tip/index.html
>
> Just my two cents to give you an idea...
>
> BR,
> Johan
> El 12/9/2015 14:44, "Michai Ramakers" escribió:
>
>> Hello,
>>
>> On 12 September 2015 at 14:34, Oliver Friedrich
>> wrote:
>> > I want to give a thought on how I use fossil regularly and on what I
>> would
>> > love as a feature.
>> >
>> > While fossil is easy to set up and maintain, I often have several small
>> > projects that seem to be to small to get an own instance of a
>> repository for
>> > themselfes. Additionally, I like to use fossil, because it reduces the
>> > number of files to manage (1 repo instead of dozens of files per
>> project).
>> >
>> > That spoken, I have bunch of code-samples and abstracted code-problems
>> in
>> > different programming languages and flavours, that I keep as personal
>> > knowledge database. I tend to give each of them its own fossil
>> repository,
>> > but as I mentioned before, sometimes they have just one or two files.
>> >
>> > My old solution was to have one repository with one set of folders for
>> each
>> > sub-project. But Timeline get messy really fast and it is hard to track
>> > sub-projects with this approach.
>> >
>> > My current solution is to have one repository with an empty initial
>> check-in
>> > tagged as ROOT. Then I do one branch per sub-project based on the ROOT
>> > check-in.
>> >
>> > That way I'm able to keep my code cleanly detached from each another,
>> but it
>> > feels really dirty - cause that's in no way the correct handling of
>> > branches.
>> >
>> > What I really would like to have is to gather multiple such small
>> projects
>> > in one repo file, so instead of having one ROOT check-in, having one
>> ROOT
>> > for each project. I know that would make developing fossil a bit
>> harder, but
>> > I think it would be a great feature and that not I'm the only one who
>> would
>> > use this.
>> >
>> > In the simpliest logic I can imagine this would mean nothing more than
>> one
>> > additional layer, branches belong to project. For the normal use, each
>> > branch would just belong to the default project. But I guess that
>> > implementing this could be much harder, especially visualizations in the
>> > web-frontend.
>> >
>> > But what do you think about multiple projects in one repo?
>> > What would be your approach on my problem?
>>
>> I think this has come up a few times on this ML; I think some
>> suggestions are to use nested repos ('fossil open --nested') or
>> indeed, branches. At least one post about disjoint timelines within a
>> project is here:
>> http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/14983
>>
>> I happen to use branches, just like you, and am fairly happy with
>> this. Nested repos were a bit overkill for me, but I guess that's
>> personal.
>>
>> Michai
>> ___
>> 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] Multiple Projects in one Repo
Hi,
After some suggestions in this ML, I chose using nested repositories.
The "root repository", which I called 'nested', only contains a few files.
All other repositories are open inside the 'nested' directory, with the
-nested option.
Here is a script which clones, opens and updates the entire nested
directory tree (fossul-setuo.sh):
http://kuu.se/fossil/nested.cgi/doc/tip/index.html
Just my two cents to give you an idea...
BR,
Johan
El 12/9/2015 14:44, "Michai Ramakers" escribió:
> Hello,
>
> On 12 September 2015 at 14:34, Oliver Friedrich
> wrote:
> > I want to give a thought on how I use fossil regularly and on what I
> would
> > love as a feature.
> >
> > While fossil is easy to set up and maintain, I often have several small
> > projects that seem to be to small to get an own instance of a repository
> for
> > themselfes. Additionally, I like to use fossil, because it reduces the
> > number of files to manage (1 repo instead of dozens of files per
> project).
> >
> > That spoken, I have bunch of code-samples and abstracted code-problems in
> > different programming languages and flavours, that I keep as personal
> > knowledge database. I tend to give each of them its own fossil
> repository,
> > but as I mentioned before, sometimes they have just one or two files.
> >
> > My old solution was to have one repository with one set of folders for
> each
> > sub-project. But Timeline get messy really fast and it is hard to track
> > sub-projects with this approach.
> >
> > My current solution is to have one repository with an empty initial
> check-in
> > tagged as ROOT. Then I do one branch per sub-project based on the ROOT
> > check-in.
> >
> > That way I'm able to keep my code cleanly detached from each another,
> but it
> > feels really dirty - cause that's in no way the correct handling of
> > branches.
> >
> > What I really would like to have is to gather multiple such small
> projects
> > in one repo file, so instead of having one ROOT check-in, having one ROOT
> > for each project. I know that would make developing fossil a bit harder,
> but
> > I think it would be a great feature and that not I'm the only one who
> would
> > use this.
> >
> > In the simpliest logic I can imagine this would mean nothing more than
> one
> > additional layer, branches belong to project. For the normal use, each
> > branch would just belong to the default project. But I guess that
> > implementing this could be much harder, especially visualizations in the
> > web-frontend.
> >
> > But what do you think about multiple projects in one repo?
> > What would be your approach on my problem?
>
> I think this has come up a few times on this ML; I think some
> suggestions are to use nested repos ('fossil open --nested') or
> indeed, branches. At least one post about disjoint timelines within a
> project is here:
> http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/14983
>
> I happen to use branches, just like you, and am fairly happy with
> this. Nested repos were a bit overkill for me, but I guess that's
> personal.
>
> Michai
> ___
> 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] diff after update
On Sat, Sep 12, 2015 at 01:10:28PM +0200, j. van den hoff wrote: > On Sat, 12 Sep 2015 01:45:28 +0200, Johan Kuuse wrote: > > >fossil diff -before > > > >or > > > >fossil diff -before-commit > > typo... I just wanted to propose another name for the requested > option, and actually I meant "call it `diff --before' or `diff > --before-update' which I for one would be able to memorize as > "compute diff of current state vs. state before the preceding > update". actually, considering the original posters `subject' line, > one might also look at it the other way round and call it `diff > --after-update' ;-) > > personally, I find reference to the undo buffer a long way from > being obvious to someone just using fossil as DVCS (rather than > someone interested in in the details/internals of `fossil'). It depend what the feature really do. As it is implemented now (if I understand it well) it make a diff against the undo buffer, doesn't matter what was the previous command. So in that case, I think it should refer to the undo buffer somehow. What if someone does : -- $ fossil update ... $ fossil stash # some hacking... $ fossil shash pop $ fossil diff --before-update(or fossil diff --undo) -- In this case, it would be confusing if it doesn't really do the diff with what was on disk before the update. Right now with the " fossil diff --undo" , it would make the diff from current file on disk with what it was before the "fossil stash pop" command. > > > > >? > >El 12/9/2015 1:14, "Andy Bradford" escribió: > > > >>Thus said Richard Hipp on Fri, 11 Sep 2015 10:11:30 -0400: > >> > >>> "fossil diff --versus-undo" maybe??? > >> > >>What if instead of making this a feature of ``fossil diff'' it became a > >>feature of ``fossil undo?'' > >> > >>fossil undo --diff I think that "fossil diff --from undo" have the advantage to be clear and represent what the command really does compare to let say: fossil undo --diff : might be interpret as it undo something fossil diff --undo : is less explicit than --from undo -- 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] Why Hash
On Fri, Sep 11, 2015 at 04:57:46PM -0600, Warren Young wrote: > I wonder if this is an implementation detail leaking through into the > UI, though. Under what conditions, except for Noam’s contrived example > with hardcoded dates, is there a useful distinction between “hash” — > implying a number that you could reliably recompute given all the input > data — and “random number”? The SHA1 hash is just a deterministic random number for this purpose. Making it deterministic just means that the identifier can also double as checksum. Joerg ___ 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] Multiple Projects in one Repo
Hello,
On 12 September 2015 at 14:34, Oliver Friedrich
wrote:
> I want to give a thought on how I use fossil regularly and on what I would
> love as a feature.
>
> While fossil is easy to set up and maintain, I often have several small
> projects that seem to be to small to get an own instance of a repository for
> themselfes. Additionally, I like to use fossil, because it reduces the
> number of files to manage (1 repo instead of dozens of files per project).
>
> That spoken, I have bunch of code-samples and abstracted code-problems in
> different programming languages and flavours, that I keep as personal
> knowledge database. I tend to give each of them its own fossil repository,
> but as I mentioned before, sometimes they have just one or two files.
>
> My old solution was to have one repository with one set of folders for each
> sub-project. But Timeline get messy really fast and it is hard to track
> sub-projects with this approach.
>
> My current solution is to have one repository with an empty initial check-in
> tagged as ROOT. Then I do one branch per sub-project based on the ROOT
> check-in.
>
> That way I'm able to keep my code cleanly detached from each another, but it
> feels really dirty - cause that's in no way the correct handling of
> branches.
>
> What I really would like to have is to gather multiple such small projects
> in one repo file, so instead of having one ROOT check-in, having one ROOT
> for each project. I know that would make developing fossil a bit harder, but
> I think it would be a great feature and that not I'm the only one who would
> use this.
>
> In the simpliest logic I can imagine this would mean nothing more than one
> additional layer, branches belong to project. For the normal use, each
> branch would just belong to the default project. But I guess that
> implementing this could be much harder, especially visualizations in the
> web-frontend.
>
> But what do you think about multiple projects in one repo?
> What would be your approach on my problem?
I think this has come up a few times on this ML; I think some
suggestions are to use nested repos ('fossil open --nested') or
indeed, branches. At least one post about disjoint timelines within a
project is here:
http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/14983
I happen to use branches, just like you, and am fairly happy with
this. Nested repos were a bit overkill for me, but I guess that's
personal.
Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Multiple Projects in one Repo
I want to give a thought on how I use fossil regularly and on what I would love as a feature. While fossil is easy to set up and maintain, I often have several small projects that seem to be to small to get an own instance of a repository for themselfes. Additionally, I like to use fossil, because it reduces the number of files to manage (1 repo instead of dozens of files per project). That spoken, I have bunch of code-samples and abstracted code-problems in different programming languages and flavours, that I keep as personal knowledge database. I tend to give each of them its own fossil repository, but as I mentioned before, sometimes they have just one or two files. My old solution was to have one repository with one set of folders for each sub-project. But Timeline get messy really fast and it is hard to track sub-projects with this approach. My current solution is to have one repository with an empty initial check-in tagged as ROOT. Then I do one branch per sub-project based on the ROOT check-in. That way I'm able to keep my code cleanly detached from each another, but it feels really dirty - cause that's in no way the correct handling of branches. What I really would like to have is to gather multiple such small projects in one repo file, so instead of having one ROOT check-in, having one ROOT for each project. I know that would make developing fossil a bit harder, but I think it would be a great feature and that not I'm the only one who would use this. In the simpliest logic I can imagine this would mean nothing more than one additional layer, branches belong to project. For the normal use, each branch would just belong to the default project. But I guess that implementing this could be much harder, especially visualizations in the web-frontend. But what do you think about multiple projects in one repo? What would be your approach on my problem? ___ 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] diff after update
On Sat, Sep 12, 2015 at 1:10 PM, j. van den hoff wrote: > personally, I find reference to the undo buffer a long way from being > obvious to someone just using fossil as DVCS (rather than someone > interested in in the details/internals of `fossil'). while i can agree with that, the whole feature is apparently non-obvious (has never been suggested before). -- - 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] diff after update
On Sat, 12 Sep 2015 01:45:28 +0200, Johan Kuuse wrote: fossil diff -before or fossil diff -before-commit typo... I just wanted to propose another name for the requested option, and actually I meant "call it `diff --before' or `diff --before-update' which I for one would be able to memorize as "compute diff of current state vs. state before the preceding update". actually, considering the original posters `subject' line, one might also look at it the other way round and call it `diff --after-update' ;-) personally, I find reference to the undo buffer a long way from being obvious to someone just using fossil as DVCS (rather than someone interested in in the details/internals of `fossil'). ? El 12/9/2015 1:14, "Andy Bradford" escribió: Thus said Richard Hipp on Fri, 11 Sep 2015 10:11:30 -0400: > "fossil diff --versus-undo" maybe??? What if instead of making this a feature of ``fossil diff'' it became a feature of ``fossil undo?'' fossil undo --diff Andy -- TAI64 timestamp: 400055f36093 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
[fossil-users] FOSSIL LS bug?
With this setting: relative-paths (local) 1 doing FOSSIL LS . from within a subdirectory displays the full path (from the root or the repo). I tried with older version and current trunk and get the same behavior. ___ 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] diff after update
On Sat, Sep 12, 2015 at 2:04 AM, Scott Robison wrote: > On Fri, Sep 11, 2015 at 5:14 PM, Andy Bradford > wrote: > >> Thus said Richard Hipp on Fri, 11 Sep 2015 10:11:30 -0400: >> >> > "fossil diff --versus-undo" maybe??? >> > i don't like 'versus' because diff already has 'from', and it seems strange to split out a special case of it, but... > >> What if instead of making this a feature of ``fossil diff'' it became a >> feature of ``fossil undo?'' >> >> fossil undo --diff >> > > Ooh, I like this... +1 > me, too. -- - 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] Why Hash
On Sat, Sep 12, 2015 at 12:57 AM, Warren Young wrote: > For instance, why even mention “SHA1 Hash” on the checkin details page in > fossil ui, from src/info.c? Why not something more generic, like “checkin > ID”? > The checkin ID is the hash of the manifest for the checkin. e.g. try: [stephan@host:~/cvs/fossil/cwal]$ f info ... checkout: c56006cd3df5400a38de9b0b7e9797f8e2f3a999 2015-08-14 15:17:09 UTC ... [stephan@host:~/cvs/fossil/cwal]$ f artifact c56006cd3df5400a38de9b0b7e9797f8e2f3a999 B f88c7a2382edcc51d004f133fa72fc462814b200 C minor\stest\scode\stweaks. D 2015-08-14T15:17:09.841 F s2/s2.c 46dc5ced9a243b20571781a6b4ac232e79ca1e27 F s2/s2.h 7ab0c333784a684f608938b676a6c1c6c09ec170 F s2/s2_ops.c 69d17c0d0b017e19d1b0c87a75153c55841a02db F s2/unit/070-000-enum.s2 19c28bc16ea5e5a30953307344740566ca373ac4 P 3aa469f15c41f9920c0b43ae47acc3da4fc821e7 R 1f0ece1803f7f3776ace86d686725d62 U stephan Z bfdac81f2888e26d15908ba724a50cf1 [stephan@host:~/cvs/fossil/cwal]$ f artifact c56006cd3df5400a38de9b0b7e9797f8e2f3a999 | sha1sum - c56006cd3df5400a38de9b0b7e9797f8e2f3a999 - note that the input hash and output hash have the same value. > While looking into this, I see evidence of past historical wrangling here: > blob.uuid, for example, even though sizeof(SHA1) != sizeof(UUID). I guess > Fossil once used MD5 for these ID values, too, and not just for integrity > checksumming? > md5 is used in a small number of places for (IIRC) speed purposes. IIRC it's only used in the calculation of the R-card (pure an integrity-checking measure). -- - 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
