Re: [fossil-users] recent change: alt-root and its purpose?

[Stephan Beal]

On Sat, Apr 28, 2012 at 1:03 PM, Leo Razoumov  wrote:

> (3)  Rational for violating long-standing Fossil design principle that
> project repo database does not know its checkouts.
>

This sounds like it might also (minorly?) complicate out-of-fossil
synchronization of repos for some users (e.g. rsync-based), since a
checkout now changes the repo file?

Regarding the unlimited growth: i've been using fossil since 2007 and have
never had any given repo checked out more than twice locally. Even with 50
entries, the storage required is minimal. (Nonetheless, i share your
curiosity about why this new feature might be needed at all.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] recent change: alt-root and its purpose?

[Leo Razoumov]

On Sat, Apr 28, 2012 at 07:25, Stephan Beal  wrote:
> On Sat, Apr 28, 2012 at 1:03 PM, Leo Razoumov  wrote:
>>
>> (3)  Rational for violating long-standing Fossil design principle that
>> project repo database does not know its checkouts.
>
>
> This sounds like it might also (minorly?) complicate out-of-fossil
> synchronization of repos for some users (e.g. rsync-based), since a checkout
> now changes the repo file?
>
> Regarding the unlimited growth: i've been using fossil since 2007 and have
> never had any given repo checked out more than twice locally. Even with 50
> entries, the storage required is minimal. (Nonetheless, i share your
> curiosity about why this new feature might be needed at all.)
>

I do checkout a repo often and multiple times -- typically, one
checkout-per-branch I am working with (for fossil-scm alone I have 5
checkouts). Please, keep in mind that "fossil open" adds a checkout
entry while "fossil close" does *NOT* remove it. Basically, a project
repo keeps accumulating checkout entries some of which refer to
deleted checkouts that no longer exist! It also clutters output of
"fossil info" command.  And, of course, it breaks rsync.

--Leo--
___
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] recent change: alt-root and its purpose?

[Richard Hipp]

On Sat, Apr 28, 2012 at 7:03 AM, Leo Razoumov  wrote:

> Hi All,
> Fossil design clearly separates a project repository database from a
> checkout database. It is explicitly stated in the Fossil
> documentation:
>
>  http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki
>  "Notice that the checkout database contains a pointer to the
> repository database but that the repository database has no record of
> the checkout databases. That means that a working checkout directory
> tree can be freely renamed or copied or deleted without consequence."
>
> Unfortunately, this in not true anymore since trunk [e604d483ee55]
> (2012-04-27 15:43:51). Now  every time you "fossil open" a repository,
> the checkout root gets recorded into config portion of the project
> repo. All the checkouts ever created are displayed as "alt-root"
> entries by "fossil info". The "alt-root" list can get long if one has
> many checkouts. By the way, "fossil close" does *NOT* remove the entry
> from the alt-root list (a bug??). The list only grows and never
> shrinks. A convenient way of dispensing with checkouts by "rm -rf
> path-to-checkout" leaves behind dangling references to non-existing
> directories.
>
> To the best of my knowledge there has been no discussion of this
> feature on the fossil-users or fossil-dev mailing lists. Therefore, I
> would greatly appreciate if someone can explain to me
>
> (1)  What is the purpose of the feature.
> (2)  Its intended use.
> (3)  Rational for violating long-standing Fossil design principle that
> project repo database does not know its checkouts.
>

I added this to help me keep track of where my check-outs are located.  I
keep all of my repositories in a single directory so I know where they all
are.  But my check-outs are scattered about hither and yon, according to
their use and function.  Many times I'll be looking at my growing
collection of repositories and wonder "where did I check this one out most
recently".   Or I'll be be working in a check-out and want to do some
unrelated change on another branch and then wonder if I have other
checkouts of the same repo sitting around anywhere.

If you are thinking of moving or renaming a Fossil repository file, a
listing of check-outs would be very useful in helping to determine what
will break and need fixing.

On a server, I often have multiple CGI scripts all pointing to the same
repository.  A similar feature, added at the same time, keeps track of all
of the possible URLs for accessing a repository.  On the main Fossil
webserver for example, I just now did "fossil info fossil.fossil" and I see
this:

access-url:   http://fossil-scm.hwaci.com/fossil
2012-04-28
access-url:   http://fossil-scm.hwaci.com/index.html
2012-04-28
access-url:   http://fossil-scm.org/fossil
2012-04-28
access-url:   http://fossil-scm.org/index.cgi
2012-04-28
access-url:   http://fossil-scm.org/index.html
2012-04-28
access-url:   http://fossil-scm.org/xfer
2012-04-28
access-url:   http://sqlite.org/debug1
2012-04-28
access-url:   http://www.fossil-scm.org//index.html
2012-04-28
access-url:   http://www.fossil-scm.org/fossil
2012-04-28
access-url:   http://www.fossil-scm.org/index.html
2012-04-28
access-url:   http://www.fossil-scm.org/xfer
2012-04-28
access-url:   http://www.sqlite.org/debug1
2012-04-28
access-url:   https://fossil-scm.org/index.html
2012-04-28
access-url:   https://www.fossil-scm.org/fossil
2012-04-28
access-url:   https://www.fossil-scm.org/index.html
2012-04-28

Those are the various URLs by which the Fossil repository has been accessed
recently.  Some are just multiple domain names assigned to the same IP
address (www.fossil-scm.org vs fossil-scm.org vs fossil-scm.hwaci.com) but
other actually reflect separate CGI scripts (index.html, index.cgi, fossil,
xfer, and debug1).  There are 65 other Fossil repositories on the same
machine.  A cross-reference like this is helpful in keeping track of where
stuff is located.  If I move or rename a repository, it gives me a quick
way to find all of the CGI scripts that will need to be updated.

Eventually, I'd like to add an enhancement whereby one can ask "Do I have
any uncommitted changes for this project, possibly in other checkouts?"
and "Do I have any uncommitted changes anywhere on this system?"  The
mapping from repositories to check-outs will help answer those questions.

Note that mapping from repository to check-out is more of a log-file
entry.  It is not required to be consistent in order for the system to
function.  It is advisory only.  So this change should not have broken
anything.

Yes, it would be nice if there was a way to cull these lists, similar to
the "fossil all ignore" command.  So many ideas... So little time...




>
> Thanks and Best Regards,
> --Leo--
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
D. Richard Hipp
d...@sqlite

Re: [fossil-users] recent change: alt-root and its purpose?

[Nolan Darilek]

On 04/28/2012 08:34 AM, Richard Hipp wrote:


Yes, it would be nice if there was a way to cull these lists, similar 
to the "fossil all ignore" command.  So many ideas... So little time...





What about a check to determine whether the directory still exists any 
time the field is queried, removing it from the table if it doesn't? 
Seems like the simplest solution, unless I'm missing something.


Thanks.
___
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] recent change: alt-root and its purpose?

[Richard Hipp]

On Sat, Apr 28, 2012 at 10:16 AM, Nolan Darilek wrote:

> On 04/28/2012 08:34 AM, Richard Hipp wrote:
>
>>
>> Yes, it would be nice if there was a way to cull these lists, similar to
>> the "fossil all ignore" command.  So many ideas... So little time...
>>
>>
>
> What about a check to determine whether the directory still exists any
> time the field is queried, removing it from the table if it doesn't? Seems
> like the simplest solution, unless I'm missing something.
>

That's a partial solution, though it isn't complete.  The directory might
still exist even though it has been repurposed and is no longer acting as a
check-out.  But, yes, that is one change that certainly needs to be made.
I'll try to get something like that implemented this weekend.


>
> Thanks.
>
> __**_
> fossil-users mailing list
> fossil-users@lists.fossil-scm.**org 
> http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users
>



-- 
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] recent change: alt-root and its purpose?

[Jos Groot Lipman]

Can or will this new feature include the date of the last update/sync of the
checkout?
It would be a great help in identifying old and obsolete checkout's


  _  

From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp
Sent: zaterdag 28 april 2012 16:29
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] recent change: alt-root and its purpose?




On Sat, Apr 28, 2012 at 10:16 AM, Nolan Darilek 
wrote:


On 04/28/2012 08:34 AM, Richard Hipp wrote:



Yes, it would be nice if there was a way to cull these lists, similar to the
"fossil all ignore" command.  So many ideas... So little time...





What about a check to determine whether the directory still exists any time
the field is queried, removing it from the table if it doesn't? Seems like
the simplest solution, unless I'm missing something.



That's a partial solution, though it isn't complete.  The directory might
still exist even though it has been repurposed and is no longer acting as a
check-out.  But, yes, that is one change that certainly needs to be made.
I'll try to get something like that implemented this weekend.
 


Thanks. 

___
fossil-users mailing list
fossil-users@lists.fossil-scm. <mailto:fossil-users@lists.fossil-scm.org>
org
http://lists.fossil-scm.org:
<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
8080/cgi-bin/mailman/listinfo/fossil-users





-- 
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] recent change: alt-root and its purpose?

[Matt Welland]

On Sat, Apr 28, 2012 at 6:34 AM, Richard Hipp  wrote:

>
>
> On Sat, Apr 28, 2012 at 7:03 AM, Leo Razoumov  wrote:
>
>> Hi All,
>> Fossil design clearly separates a project repository database from a
>> checkout database. It is explicitly stated in the Fossil
>> documentation:
>>
>>  http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki
>>  "Notice that the checkout database contains a pointer to the
>> repository database but that the repository database has no record of
>> the checkout databases. That means that a working checkout directory
>> tree can be freely renamed or copied or deleted without consequence."
>>
>> Unfortunately, this in not true anymore since trunk [e604d483ee55]
>> (2012-04-27 15:43:51). Now  every time you "fossil open" a repository,
>> the checkout root gets recorded into config portion of the project
>> repo. All the checkouts ever created are displayed as "alt-root"
>> entries by "fossil info". The "alt-root" list can get long if one has
>> many checkouts. By the way, "fossil close" does *NOT* remove the entry
>> from the alt-root list (a bug??). The list only grows and never
>> shrinks. A convenient way of dispensing with checkouts by "rm -rf
>> path-to-checkout" leaves behind dangling references to non-existing
>> directories.
>>
>> To the best of my knowledge there has been no discussion of this
>> feature on the fossil-users or fossil-dev mailing lists. Therefore, I
>> would greatly appreciate if someone can explain to me
>>
>> (1)  What is the purpose of the feature.
>> (2)  Its intended use.
>> (3)  Rational for violating long-standing Fossil design principle that
>> project repo database does not know its checkouts.
>>
>
> I added this to help me keep track of where my check-outs are located.  I
> keep all of my repositories in a single directory so I know where they all
> are.  But my check-outs are scattered about hither and yon, according to
> their use and function.  Many times I'll be looking at my growing
> collection of repositories and wonder "where did I check this one out most
> recently".   Or I'll be be working in a check-out and want to do some
> unrelated change on another branch and then wonder if I have other
> checkouts of the same repo sitting around anywhere.
>
>
Isn't this information also stored in ~/.fossil as
"ckout:/path/to/ckout|/path/to/repo.fossil" entries? I think I'd prefer to
see the data recorded just once and actually I think the ~/.fossil file is
a better place. Those entries should meet all your requirements as it maps
each repo db to a checkout. Even if the repo db was moved there is enough
data available to find the mapping and update the pointers in the _FOSSIL_
files.

Since I can't get fossil ssh to work we are using rsync to sync fossils
cross-site and with this feature every time someone blows away a repo and
re-gets it the rsync logs will show a transfer implying that a change was
made. Not a big deal but confusing and an annoyance nonetheless.

If the decision is to stick with the new method then please consider
removing the code that adds the ckout: entries to ~/.fossil as people will
write automation that relies on one or the other and that can get messy and
chaotic when there is not one canonical source data location.


> If you are thinking of moving or renaming a Fossil repository file, a
> listing of check-outs would be very useful in helping to determine what
> will break and need fixing.
>
> On a server, I often have multiple CGI scripts all pointing to the same
> repository.  A similar feature, added at the same time, keeps track of all
> of the possible URLs for accessing a repository.  On the main Fossil
> webserver for example, I just now did "fossil info fossil.fossil" and I see
> this:
>
> access-url:   http://fossil-scm.hwaci.com/fossil
> 2012-04-28
> access-url:   http://fossil-scm.hwaci.com/index.html
> 2012-04-28
> access-url:   http://fossil-scm.org/fossil
> 2012-04-28
> access-url:   http://fossil-scm.org/index.cgi
> 2012-04-28
> access-url:   http://fossil-scm.org/index.html
> 2012-04-28
> access-url:   http://fossil-scm.org/xfer
> 2012-04-28
> access-url:   http://sqlite.org/debug1
> 2012-04-28
> access-url:   http://www.fossil-scm.org//index.html
> 2012-04-28
> access-url:   http://www.fossil-scm.org/fossil
> 2012-04-28
> access-url:   http://www.fossil-scm.org/index.html
> 2012-04-28
> access-url:   http://www.fossil-scm.org/xfer
> 2012-04-28
> access-url:   http://www.sqlite.org/debug1
> 2012-04-28
> access-url:   https://fossil-scm.org/index.html
> 2012-04-28
> access-url:   https://www.fossil-scm.org/fossil
> 2012-04-28
> access-url:   https://www.fossil-scm.org/index.html
> 2012-04-28
>
> Those are the various URLs by which the Fossil repository has been
> accessed recently.  Some are just multiple domain names assigned to the
> same IP address (www.fossil-scm.org vs fossil-scm.org vs
> fossil-scm.hwaci.com) but other actually reflect separate CGI scripts
> (index.html, index.cgi, fossil, x

Re: [fossil-users] recent change: alt-root and its purpose?

[Leo Razoumov]

On Sat, Apr 28, 2012 at 13:00, Matt Welland  wrote:
> On Sat, Apr 28, 2012 at 6:34 AM, Richard Hipp  wrote:
>> On Sat, Apr 28, 2012 at 7:03 AM, Leo Razoumov  wrote:
>>>
>>> Hi All,
>>> Fossil design clearly separates a project repository database from a
>>> checkout database. It is explicitly stated in the Fossil
>>> documentation:
>>>
>>>  http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki
>>>  "Notice that the checkout database contains a pointer to the
>>> repository database but that the repository database has no record of
>>> the checkout databases. That means that a working checkout directory
>>> tree can be freely renamed or copied or deleted without consequence."
>>>
>>> Unfortunately, this in not true anymore since trunk [e604d483ee55]
>>> (2012-04-27 15:43:51). Now  every time you "fossil open" a repository,
>>> the checkout root gets recorded into config portion of the project
>>> repo. All the checkouts ever created are displayed as "alt-root"
>>> entries by "fossil info". The "alt-root" list can get long if one has
>>> many checkouts. By the way, "fossil close" does *NOT* remove the entry
>>> from the alt-root list (a bug??). The list only grows and never
>>> shrinks. A convenient way of dispensing with checkouts by "rm -rf
>>> path-to-checkout" leaves behind dangling references to non-existing
>>> directories.
>>>
>>> To the best of my knowledge there has been no discussion of this
>>> feature on the fossil-users or fossil-dev mailing lists. Therefore, I
>>> would greatly appreciate if someone can explain to me
>>>
>>> (1)  What is the purpose of the feature.
>>> (2)  Its intended use.
>>> (3)  Rational for violating long-standing Fossil design principle that
>>> project repo database does not know its checkouts.
>>
>>
>> I added this to help me keep track of where my check-outs are located.  I
>> keep all of my repositories in a single directory so I know where they all
>> are.  But my check-outs are scattered about hither and yon, according to
>> their use and function.  Many times I'll be looking at my growing collection
>> of repositories and wonder "where did I check this one out most recently".
>> Or I'll be be working in a check-out and want to do some unrelated change on
>> another branch and then wonder if I have other checkouts of the same repo
>> sitting around anywhere.
>>
>
> Isn't this information also stored in ~/.fossil as
> "ckout:/path/to/ckout|/path/to/repo.fossil" entries? I think I'd prefer to
> see the data recorded just once and actually I think the ~/.fossil file is a
> better place. Those entries should meet all your requirements as it maps
> each repo db to a checkout. Even if the repo db was moved there is enough
> data available to find the mapping and update the pointers in the _FOSSIL_
> files.
>
> Since I can't get fossil ssh to work we are using rsync to sync fossils
> cross-site and with this feature every time someone blows away a repo and
> re-gets it the rsync logs will show a transfer implying that a change was
> made. Not a big deal but confusing and an annoyance nonetheless.
>
> If the decision is to stick with the new method then please consider
> removing the code that adds the ckout: entries to ~/.fossil as people will
> write automation that relies on one or the other and that can get messy and
> chaotic when there is not one canonical source data location.
>

Matt,
very good point!  IMHO,  "~/.fossil" is, indeed, the best place to
keep track of the existing checkouts. One can also write a script that
loops through the checkouts in ~/.fossil and removes the dangling
references and/or lists checkouts with uncommitted changes.

--Leo--
___
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] recent change: alt-root and its purpose?

[Leo Razoumov]

On Sat, Apr 28, 2012 at 09:34, Richard Hipp  wrote:
>
> On a server, I often have multiple CGI scripts all pointing to the same
> repository.  A similar feature, added at the same time, keeps track of all
> of the possible URLs for accessing a repository.  On the main Fossil
> webserver for example, I just now did "fossil info fossil.fossil" and I see
> this:
>
> access-url:   http://fossil-scm.hwaci.com/fossil
> 2012-04-28
> 

I think this means that every time one accesses a repository via
cg-bin the repository updates the "baseurl:..." entry. This would make
rsync based replication/backup scripts go nuts (they depend on
timestamps and checksums).

Would it be better to have a configuration settings "track-access"
(on/off) and "track-ckout" (on/off) to allow a user to selectively
enable/disable new behavior according to his/her needs?

--Leo--
___
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] recent change: alt-root and its purpose?

[Richard Hipp]

On Mon, Apr 30, 2012 at 8:17 AM, Leo Razoumov  wrote:

> On Sat, Apr 28, 2012 at 09:34, Richard Hipp  wrote:
> >
> > On a server, I often have multiple CGI scripts all pointing to the same
> > repository.  A similar feature, added at the same time, keeps track of
> all
> > of the possible URLs for accessing a repository.  On the main Fossil
> > webserver for example, I just now did "fossil info fossil.fossil" and I
> see
> > this:
> >
> > access-url:   http://fossil-scm.hwaci.com/fossil
> > 2012-04-28
> > 
>
> I think this means that every time one accesses a repository via
> cg-bin the repository updates the "baseurl:..." entry. This would make
> rsync based replication/backup scripts go nuts (they depend on
> timestamps and checksums).
>

No.  The entry is only updated if it does not previously exist or if the
database file was changing for some other reason.

Note that the database already gets updated every time somebody signs in.
And Fossil uses the database as a cache in some circumstances, so already
many if not most CGI accesses already write to the database file.  This has
been the case for ages.

Note that rsync only transmits the differences between two files, so making
small changes to one table is not going to seriously impact rsync
performance.  The www.fossil-scm.org website is backed up using rsync.

And, really, "fossil sync" is a better backup of repositories than "rsync"
anyhow.




>
> Would it be better to have a configuration settings "track-access"
> (on/off) and "track-ckout" (on/off) to allow a user to selectively
> enable/disable new behavior according to his/her needs?
>
> --Leo--
>



-- 
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] recent change: alt-root and its purpose?

[Matt Welland]

On Mon, Apr 30, 2012 at 5:31 AM, Richard Hipp  wrote:

> On Mon, Apr 30, 2012 at 8:17 AM, Leo Razoumov  wrote:
>
>> On Sat, Apr 28, 2012 at 09:34, Richard Hipp  wrote:
>>
>
[snip]


>  I think this means that every time one accesses a repository via
>> cg-bin the repository updates the "baseurl:..." entry. This would make
>> rsync based replication/backup scripts go nuts (they depend on
>> timestamps and checksums).
>>
>
> No.  The entry is only updated if it does not previously exist or if the
> database file was changing for some other reason.
>
> Note that the database already gets updated every time somebody signs in.
> And Fossil uses the database as a cache in some circumstances, so already
> many if not most CGI accesses already write to the database file.  This has
> been the case for ages.
>
> Note that rsync only transmits the differences between two files, so
> making small changes to one table is not going to seriously impact rsync
> performance.  The www.fossil-scm.org website is backed up using rsync.
>
> And, really, "fossil sync" is a better backup of repositories than "rsync"
> anyhow.
>

Ok, since the *only* time the fossil db is modified is on "fossil open"
then the impact here is less than my first impression. The only request I
have is that should the db being "opened" be read-only that a warning is
issued and the open proceeds normally. This means that in those situations
where it is needed to open a db that is read-only no extra steps are
required but if someone mistakenly opens a read-only db then they get a
nice big WARNING.


Would it be better to have a configuration settings "track-access"
>> (on/off) and "track-ckout" (on/off) to allow a user to selectively
>> enable/disable new behavior according to his/her needs?
>>
>> --Leo--
>>
>
>
>
> --
> 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
>
>
___
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] recent change: alt-root and its purpose?

[Leo Razoumov]

On Mon, Apr 30, 2012 at 08:31, Richard Hipp  wrote:
> On Mon, Apr 30, 2012 at 8:17 AM, Leo Razoumov  wrote:
>>
>> I think this means that every time one accesses a repository via
>> cg-bin the repository updates the "baseurl:..." entry. This would make
>> rsync based replication/backup scripts go nuts (they depend on
>> timestamps and checksums).
>
> No.  The entry is only updated if it does not previously exist or if the
> database file was changing for some other reason.
>

Please, correct me if I am wrong but in src/main.c
http://www.fossil-scm.org/fossil/artifact/049447e6be?ln=1097-1107
"cmd_cgi" will always insert/replace "baseurl:..." entry as long as
the repository is writable.

--Leo--
___
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] recent change: alt-root and its purpose?

[Richard Hipp]

On Mon, Apr 30, 2012 at 2:16 PM, Leo Razoumov  wrote:

> On Mon, Apr 30, 2012 at 08:31, Richard Hipp  wrote:
> > On Mon, Apr 30, 2012 at 8:17 AM, Leo Razoumov 
> wrote:
> >>
> >> I think this means that every time one accesses a repository via
> >> cg-bin the repository updates the "baseurl:..." entry. This would make
> >> rsync based replication/backup scripts go nuts (they depend on
> >> timestamps and checksums).
> >
> > No.  The entry is only updated if it does not previously exist or if the
> > database file was changing for some other reason.
> >
>
> Please, correct me if I am wrong but in src/main.c
> http://www.fossil-scm.org/fossil/artifact/049447e6be?ln=1097-1107
> "cmd_cgi" will always insert/replace "baseurl:..." entry as long as
> the repository is writable.
>

db_optional_sql() only runs if some other write operation is also taking
place.  So if the repo is only being read by the CGI, then
db_optional_sql() is a no-op.


>
> --Leo--
>



-- 
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