Never mind ... This is the list of changed files, and you want the _full_ list.
Ok. Yeah, that is only in the manifest I believe.

On Wed, Nov 26, 2014 at 10:51 AM, Andreas Kupries
<andre...@activestate.com> wrote:
> On Wed, Nov 26, 2014 at 10:46 AM, Stephan Beal <sgb...@googlemail.com> wrote:
>> On Wed, Nov 26, 2014 at 7:33 PM, Baruch Burstein <bmburst...@gmail.com>
>> wrote:
>>>
>>> P.S. If changing the schema is indeed a big deal that you would rather
>>> avoid as much as possible, and if you do decide to go ahead and change it
>>> now, maybe you can have a look at this bug
>>> (http://fossil-scm.org/index.html/tktview?name=d26a9d9e2b) too. I am not
>>> sure how to fix it myself, but I think that fixing it may require a schema
>>> change, and if so you might as well do all the changes in one release.
>>
>>
>> Now that you mention it... i also have a small schema wish: i want the full
>> list of files for a given checkin.  i've banged my head over SQL-only
>> solutions, and don't see how to get it without parsing the manifest. It
>> would be easy to add during crosslinking, but there's currently no place for
>> it (and i'm not quite certain where it would fit best).
>
> FX currently uses
>
> proc ::fx::fossil::changeset {uuid} {
>     debug.fx/fossil {}
>     set r {}
>     repository eval {
>         SELECT filename.name AS thepath,
>                CASE WHEN nullif(mlink.pid,0) is null THEN 'added'
>                     WHEN nullif(mlink.fid,0) is null THEN 'deleted'
>                     ELSE                                  'edited'
>                END AS theaction
>         FROM   mlink, filename, blob
>         WHERE  mlink.mid  = blob.rid
>         AND    blob.uuid = :uuid
>         AND    mlink.fnid = filename.fnid
>         ORDER BY filename.name
>     } {
>         dict lappend r $theaction $thepath
>     }
>     return $r
> }
>
> to get the list of files and ops directly out of the database, without
> parsing the manifest.
> Of coursde, for the mail generation I still mine the manifest for lots
> of the other info.
>
>
>
>
>>
>> My point was really only to float the idea of doing a "schema change
>> sprint," where we bundle such changes up for a "rebuild release."
>>
>> --
>> ----- 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-dev mailing list
>> fossil-dev@lists.fossil-scm.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
>>
>
>
>
> --
> Andreas Kupries
> Senior Tcl Developer
> Code to Cloud: Smarter, Safer, Fasterâ„¢
> F: 778.786.1133
> andre...@activestate.com, http://www.activestate.com
> Learn about Stackato for Private PaaS: http://www.activestate.com/stackato



-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Fasterâ„¢
F: 778.786.1133
andre...@activestate.com, http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato
_______________________________________________
fossil-dev mailing list
fossil-dev@lists.fossil-scm.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev

Reply via email to