[fossil-users] creation-date of files/subdirs in a dir, from command-line
Hello, in the past I have sometimes encoded the date-of-creation of a dir into the dir-name. I am guessing this is a bit silly, because this information is exactly what is provided by an SCM-tool such as fossil. Can I, given a subdir in the working tree, quickly get an overview of creation-dates of files/dirs in that dir (recursive or toplevel-only, that's mostly irrelevant to me), using the CLI? (I was searching for something like the CLI-version of 'fileage?glob=', with dates printed as absolute dates rather than relative dates. That would be quite sufficient.) Ideas are welcome, Michai ___ 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] creation-date of files/subdirs in a dir, from command-line
On 18 July 2014 12:14, Michai Ramakers m.ramak...@gmail.com wrote: in the past I have sometimes encoded the date-of-creation of a dir into the dir-name. ...assuming there are actual files in that dir. ___ 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] creation-date of files/subdirs in a dir, from command-line
On 18 July 2014 12:14, Michai Ramakers m.ramak...@gmail.com wrote: Can I, given a subdir in the working tree, quickly get an overview of creation-dates of files/dirs in that dir (recursive or toplevel-only, that's mostly irrelevant to me), using the CLI? ok, 'fossil ls --age', should have looked a bit longer. Sorry for the noise once again :-) Michai ___ 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] creation-date of files/subdirs in a dir, from command-line
On Fri, Jul 18, 2014 at 12:14 PM, Michai Ramakers m.ramak...@gmail.com wrote: in the past I have sometimes encoded the date-of-creation of a dir into the dir-name. I am guessing this is a bit silly, because this information is exactly what is provided by an SCM-tool such as fossil. i don't have an answer to your question, but note that the timestamp of a dir gets changed every time a file in that dir is added or removed (possibly at other times): [odroid@host:~/fossil/libfossil/s2]$ l -d ../th1ish drwxr-xr-x 5 odroid odroid 4096 Jul 17 21:23 ../th1ish [odroid@host:~/fossil/libfossil/s2]$ touch ../th1ish/foo.bar [odroid@host:~/fossil/libfossil/s2]$ l -d ../th1ish drwxr-xr-x 5 odroid odroid 4096 Jul 18 12:20 ../th1ish -- - 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] creation-date of files/subdirs in a dir, from command-line
On 18 July 2014 12:20, Stephan Beal sgb...@googlemail.com wrote: On Fri, Jul 18, 2014 at 12:14 PM, Michai Ramakers m.ramak...@gmail.com wrote: in the past I have sometimes encoded the date-of-creation of a dir into the dir-name. I am guessing this is a bit silly, because this information is exactly what is provided by an SCM-tool such as fossil. i don't have an answer to your question, but note that the timestamp of a dir gets changed every time a file in that dir is added or removed (possibly at other times): Ok, thx. (A bit of background: these dirs here with encoded date in the dirname were mostly for sets-of-files sent out to others on this-and-that date, i.o.w. stuff that was created once, never changed (long) afterwards, and basically just sitting there on the disk/repo. 'fossil ls --age' makes a lot of sense there, i.e. gives me the creation-date, or at least date of last change before sending it off. For often-changing stuff, encoding date in a dirname would make little sense anyway.) Michai ___ 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] libfossil: new script binding
On Thu, Jul 17, 2014 at 8:38 PM, Stephan Beal sgb...@googlemail.com wrote:
Unless i get called off of vacation back to work next week, i should
have the remaining bits ported from the older binding by this time next
week.
The core API bits have all been ported to s2. Sample scripts/unit tests:
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/dir/s2/unit2
There's some utility-level code left to port (filesystem utils and such),
but it's break time and that can be copy/pasted-in as needed.
Interactively...
[odroid@host:~/fossil/libfossil/s2]$ ./s2sh -v
...
s2 var f = Fossil.Context.new()
result: Context@0x7a9d8[scope=#1@0xbe94e0a0 ref#=1] == Context@0x7a9d8
s2 assert f inherits Fossil.Context
result: bool@0x73518[scope=#0@(nil) ref#=0] == true
s2 f.openCheckout()
result: Context@0x7a9d8[scope=#1@0xbe94e0a0 ref#=1] == Context@0x7a9d8
s2 f.db.each({sql:'select * from event order by mtime desc limit 3',
callback:'print(this)'})
[ci, 2456857.048176, 5822, null, null, null, null, stephan, null,
Ported Fossil.Context class from th1ish to s2., null, 2456857.048176]
[ci, 2456857.047004, 5816, null, null, null, null, stephan, null,
th1ish binding: fixed a range check., null, 2456857.047004]
[ci, 2456856.928443, 5814, null, null, null, null, stephan, null, s2:
Ported Buffer.compress/uncompress/isCompressed(), Buffer.md5(),
Buffer.sha1(), null, 2456856.928443]
result: Db@0x8c600[scope=#1@0xbe94e0a0 ref#=1] == Db@0x8c600
Happy fossiling!
--
- 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
[fossil-users] Autosync failed, database is locked
I'm using the latest tip version of Fossil, and am getting this complaint on checkins: Autosync: http://me@server:3691/server Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 343 bytes sent, 716 bytes received vim ../../ci-comment-B545A069E3EC.txt New_Version: ec88709387828f239483256ca8f66f8b1f537c5c Autosync: http://me@server:3691/server Round-trips: 1 Artifacts sent: 2 received: 0 Error: Database error: SQL error: database is locked Round-trips: 1 Artifacts sent: 2 received: 0 Sync finished with 1489 bytes sent, 252 bytes received Autosync failed. The odd port number is just a value I picked, the svn port + 1. The Fossil DB is actually on the server I'm doing the checkin on, but I switched from a direct file open to an http:// sync when I first started getting DB locking complaints, thinking that fossil server was keeping the DB locked. But, now that I'm checking in via HTTP, so that everything goes through the same fossil instance, I don't see who else could have the DB locked. The DB is on a local ext3 filesystem, so there shouldn't be anything going on related to non-POSIX semantics. This is a newly-converted svn repo, so I can't tell if this is new behavior. I've killed the background fossil instance and restarted it. ___ 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] Autosync failed, database is locked
On Fri, Jul 18, 2014 at 11:25 AM, Warren Young war...@etr-usa.com wrote: I'm using the latest tip version of Fossil, and am getting this complaint on checkins: Autosync: http://me@server:3691/server Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 343 bytes sent, 716 bytes received vim ../../ci-comment-B545A069E3EC.txt New_Version: ec88709387828f239483256ca8f66f8b1f537c5c Autosync: http://me@server:3691/server Round-trips: 1 Artifacts sent: 2 received: 0 Error: Database error: SQL error: database is locked Round-trips: 1 Artifacts sent: 2 received: 0 Sync finished with 1489 bytes sent, 252 bytes received Autosync failed. Presumably you get the same error when you do fossil sync or fossil push, right? -- 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] libfossil: new script binding
On Fri, Jul 18, 2014 at 3:27 PM, Stephan Beal sgb...@googlemail.com wrote: The core API bits have all been ported to s2. Sample scripts/unit tests: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/dir/s2/unit2 There's some utility-level code left to port (filesystem utils and such) Done - only thing missing now is the CGI layer, but i'm in no hurry to port that. And because source code just isn't enough, here are the docs: https://docs.google.com/document/d/13gRSl6-bj3LV-OKgE-BsqvqF33UFYW3oa3A2OJC5QSY/view Happy Fossiling! -- - 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] Autosync failed, database is locked
Thus said Warren Young on Fri, 18 Jul 2014 09:25:12 -0600: The DB is on a local ext3 filesystem, so there shouldn't be anything going on related to non-POSIX semantics. Is the repository that the server is serving up an actual file, or is it a link of some kind? Andy -- TAI64 timestamp: 400053c94338 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] committing to a *new* branch from a closed branch not currently possible?
It seems it is not possible to commit to a new branch from a closed branch. this is version 1.28. I think this should be allowed. Closing a branch only implies to me that no more commits are to be made to that branch. -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Autosync failed, database is locked
On 7/18/2014 09:28, Richard Hipp wrote: Presumably you get the same error when you do fossil sync or fossil push, right? Actually, I think I just figured it out: $ fossil server /museum # where I keep my *.fossils $ fossil open /museum/repo.fossil $ fossil sync http://me@server/repo ...hack, hack, hack... $ fossil ci Facepalm, right? For those who haven't immediately seen the problem, ci fails because Fossil still knows its DB file is /museum/repo.fossil despite the sync command, but fossil server is also trying to use that same DB file at the same time. The fix: you really do need a second DB copy to develop against, even when there's a perfectly good copy already on the machine, running underneath fossil server. ci commands against the development copy update the development DB, then autosync merges that change into the copy fossil server is using. I didn't run into this before because my Fossil server was remote from the development box, and I never tried fossil open on the server. ___ 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think this should be allowed. Closing a branch only implies to me that
no more commits are to be made to that branch.
The offending code is in checkin.c:
/*
** Do not allow a commit against a closed leaf
*/
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_CLOSED, vid) ){
fossil_fatal(cannot commit against a closed leaf);
}
i unfortunately cannot say how that query needs to be changed to catch
that, but i'm betting that Jan can.
--
- 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] committing to a *new* branch from a closed branch not currently possible?
Stephan Beal wrote:
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think this should be allowed. Closing a branch only implies to me that
no more commits are to be made to that branch.
The offending code is in checkin.c:
/*
** Do not allow a commit against a closed leaf
*/
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_CLOSED, vid) ){
fossil_fatal(cannot commit against a closed leaf);
}
i unfortunately cannot say how that query needs to be changed to catch
that, but i'm betting that Jan can.
From http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki:
==
Closed Leaf
A closed leaf is any leaf with the closed tag. These leaves are
intended to never be extended with descendants and hence are omitted
from lists of leaves in the command-line and web interface.
==
The docs appear quite clear that the behavior OP complains about is
intentional: regardless of whether the new check-in goes to a
different branch, the new check-in is a direct descendant of the closed
leaf. Probably the OP should just re-open the leaf and commit against
it.
--
Eric A. Rubin-Smith
___
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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 10:23 AM, Eric Rubin-Smith eas@gmail.com
wrote:
Stephan Beal wrote:
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com
wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think this should be allowed. Closing a branch only implies to me
that
no more commits are to be made to that branch.
The offending code is in checkin.c:
/*
** Do not allow a commit against a closed leaf
*/
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_CLOSED, vid) ){
fossil_fatal(cannot commit against a closed leaf);
}
i unfortunately cannot say how that query needs to be changed to catch
that, but i'm betting that Jan can.
From http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki:
==
Closed Leaf
A closed leaf is any leaf with the closed tag. These leaves are
intended to never be extended with descendants and hence are omitted
from lists of leaves in the command-line and web interface.
==
The docs appear quite clear that the behavior OP complains about is
intentional: regardless of whether the new check-in goes to a
different branch, the new check-in is a direct descendant of the closed
leaf. Probably the OP should just re-open the leaf and commit against
it.
In that case I'd suggest a new mechanism - locked with the behavior I
described.
--
Eric A. Rubin-Smith
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
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] committing to a *new* branch from a closed branch not currently possible?
Matt Welland wrote: From http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki: == Closed Leaf A closed leaf is any leaf with the closed tag. These leaves are intended to never be extended with descendants and hence are omitted from lists of leaves in the command-line and web interface. == The docs appear quite clear that the behavior OP complains about is intentional: regardless of whether the new check-in goes to a different branch, the new check-in is a direct descendant of the closed leaf. Probably the OP should just re-open the leaf and commit against it. In that case I'd suggest a new mechanism - locked with the behavior I described. I dunno. In my mind one of fossil's big advantages is that stays out of your way because it has a limited number of concepts you have to deal with. This leaves your brain free to write code. Absent some stronger argument to the contrary, I'd personally hate to see the devs add a new concept to address your relatively narrow use case. Especially since your new concept has significant semantic overlap with the existing thing, and since getting the behavior you want is pretty darn simple with the existing feature set (just re-open the branch). That's just $.02 from another user though. If you will allow me to guess the reason for your request -- is it because you have released to customers against the head of some branch, and wish to leave that leaf locked so that you have a clear idea of what you have released, may return to it, may write patches against it, etc? If so, then FWIW the SQLite and Fossil devs deal with this case by merely tagging the version. E.g. released-8.6.1b3 or whatever. You can always get back to that version (fossil update released-8.6.1b3), can always make a new branch from it. This is orthogonal to the closed-ness of a branch. Under this model, you'd picture every check-in you've tagged under your versioning scheme as a locked thing, since you're being careful not to reuse your version tags and since in Fossil the check-ins themselves are immutable. -- Eric A. Rubin-Smith ___ 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 1:16 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think this should be allowed. Closing a branch only implies to me that
no more commits are to be made to that branch.
The offending code is in checkin.c:
/*
** Do not allow a commit against a closed leaf
*/
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_CLOSED, vid) ){
fossil_fatal(cannot commit against a closed leaf);
}
i unfortunately cannot say how that query needs to be changed to catch
that, but i'm betting that Jan can.
To get the feature Matt suggested, I suggested adding a new Fossil defined
tag and adding the the following after the code cited above (inserting the
needed conditional in the new if):
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if( /* not creating new branch */ ){
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_BRCLOSED, vid) ){
fossil_fatal(cannot commit into a closed branch);
}
}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] What is a baseline?
fossil help timeline talks about a BASELINE. I've discovered by playing that it can be an artifact ID, but I assume there has to be more to it than that, else why use a different term? Neither the Schimpf book nor fossil help really explain the term. It doesn't appear on the documentation index page or in the FAQ. Can a tag name be a baseline? ___ 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 8:23 PM, Ron W ronw.m...@gmail.com wrote:
To get the feature Matt suggested, I suggested adding a new Fossil defined
tag and adding the the following after the code cited above (inserting the
needed conditional in the new if):
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if( /* not creating new branch */ ){
Very elegant :).
Eric makes a good argument for not doing it, though, and i'm interested to
see how the discussion goes. Locked, as Matt suggests it, might be
interesting, so long as it doesn't go anywhere near the semantics of
locking in RCS/CVS/etc (that discussion has been had a few times already).
--
- 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] committing to a *new* branch from a closed branch not currently possible?
The scenario I'd like to see supported is roughly as follows:
Work on a release is done. The release manager closes the branch so no one
can accidentally merge or commit to it.
A bug fix is needed. The developer branches off the closed node and fixes
the bug and runs QA.
The release manager can examine the bug fix, assess the QA results and then
open the closed branch, merge the fix and re-close.
I think this is a useful release flow.
On Fri, Jul 18, 2014 at 11:23 AM, Ron W ronw.m...@gmail.com wrote:
On Fri, Jul 18, 2014 at 1:16 PM, Stephan Beal sgb...@googlemail.com
wrote:
On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com
wrote:
It seems it is not possible to commit to a new branch from a closed
branch. this is version 1.28.
I think this should be allowed. Closing a branch only implies to me that
no more commits are to be made to that branch.
The offending code is in checkin.c:
/*
** Do not allow a commit against a closed leaf
*/
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_CLOSED, vid) ){
fossil_fatal(cannot commit against a closed leaf);
}
i unfortunately cannot say how that query needs to be changed to catch
that, but i'm betting that Jan can.
To get the feature Matt suggested, I suggested adding a new Fossil defined
tag and adding the the following after the code cited above (inserting the
needed conditional in the new if):
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if( /* not creating new branch */ ){
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_BRCLOSED, vid) ){
fossil_fatal(cannot commit into a closed branch);
}
}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
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] What is a baseline?
On Fri, Jul 18, 2014 at 8:30 PM, Warren Young war...@etr-usa.com wrote: fossil help timeline talks about a BASELINE. I've discovered by playing that it can be an artifact ID, but I assume there has to be more to it than that, else why use a different term? Neither the Schimpf book nor fossil help really explain the term. It doesn't appear on the documentation index page or in the FAQ. A baseline is a side-effect of fossil's delta manifests. Originally, fossil required that all files belonging to a give version be included in that checkin's manifest (the official metadata). That proved to be problematic for repos with large numbers (thousands) of files, as it has to record thousands of files in a list when only one changed. List member Joerg Sonnenberg (spelling?) urged Richard to find a solution, and that solution was delta manifests. A baseline is a normal checkin record. A delta manifest is a checkin record which records only files which changed between its own version and the baseline version. Any given non-delta checkin can be a baseline for arbitrary other delta manifests. If a delta gets too big, a new baseline checkin is created with all the files listed in it, and further deltas can be generated from that one. i've got a simple browser which might make this clearer: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest see the Parent/Baseline links, click those, and note the UUIDs. Sometimes the parent and baseline are the same, but not always. Typically any given baseline stays a baseline of its successors until the list of file changes gets to some computed portion of the original file list, at which point it is considered to be too far removed from the current version and a new baseline is created. So, in short: a baseline manifest is simply a checkin record (i.e. manifest) which is _not_ a delta manifest. Whether or not it actually acts as a baseline for any deltas is unimportant (maybe it does not now, but will tomorrow). Can a tag name be a baseline? No - only checkin records can. Originally, checkins were called manifests, but the word manifest now has several meanings. See: http://fossil.wanderinghorse.net/repos/libfossil/doxygen/page_terminology.html i hope that makes some sort of sense. -- - 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] What is a baseline?
Baseline is an older name for check-in. It drives from DO-178B language. We should updates the timeline help to say check-in instead, as that will be clearer to most readers, I think. On Fri, Jul 18, 2014 at 2:30 PM, Warren Young war...@etr-usa.com wrote: fossil help timeline talks about a BASELINE. I've discovered by playing that it can be an artifact ID, but I assume there has to be more to it than that, else why use a different term? Neither the Schimpf book nor fossil help really explain the term. It doesn't appear on the documentation index page or in the FAQ. Can a tag name be a baseline? ___ 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] Getting a list of what's changed since the last release
On Fri, Jul 18, 2014 at 8:39 PM, Warren Young war...@etr-usa.com wrote: When I am assembling a new software release, I assemble a ChangeLog from the checkin comments since the last release. Prior to moving to Fossil, I used svn log -r12345:HEAD for this. That lists the checkin comments from r12345 to the current version, only for files in the current directory and below, and only on the current branch. Here's how we do it for fossil releases: http://www.fossil-scm.org/fossil/vdiff?from=releaseto=trunkdetail=1 where 'release' is a tag which gets places on the most recent release. You would need, for branch-side work, to put the proper branch name there, but i think it should just work if you do that. -- - 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] Getting a list of what's changed since the last release
On Fri, Jul 18, 2014 at 2:39 PM, Warren Young war...@etr-usa.com wrote: When I am assembling a new software release, I assemble a ChangeLog from the checkin comments since the last release. On SQLite and on Fossil I do this: http://www.sqlite.org/src/timeline?a=releaset=trunkn=1000 http://www.fossil-scm.org/index.html/timeline?a=releaset=trunkn=1000 The above assumes (1) the previous release is labeled with a tag release and (2) the branch of interest is trunk and (3) there have been fewer than 1000 check-ins on trunk since the previous release. Make adjustments as necessary. Prior to moving to Fossil, I used svn log -r12345:HEAD for this. That lists the checkin comments from r12345 to the current version, only for files in the current directory and below, and only on the current branch. The closest I've come to that so far with Fossil is: $ fossil timeline after 462b6b3bc5 -n 0 The artifact ID is that of the last checkin on this branch before the ChangeLog was updated for the *previous* release. So, this tells me what happened between that release and now. The problem is, it includes all changes in the repository, not just those for the current branch. Ideally, I'd want to restrict it to the current subtree, too, as svn does. I notice that the Branches tab of fossil ui is able to get a timeline for a specific branch, somehow. I want to get it from the command line because I actually do this from within vi: :r !fossil timeline ... etc That is, the output of fossil timeline gets put into the editor at the current position. This turns the ChangeLog assembly task into an editing task, rather than a transcription task. ___ 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] Getting a list of what's changed since the last release
On Fri, Jul 18, 2014 at 8:43 PM, Stephan Beal sgb...@googlemail.com wrote: Here's how we do it for fossil releases: http://www.fossil-scm.org/fossil/vdiff?from=releaseto=trunkdetail=1 Correction: that's the diff for that range. Richard's solution gives you the commit comments. -- - 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 2:17 PM, Eric Rubin-Smith eas@gmail.com wrote: Matt Welland wrote: In that case I'd suggest a new mechanism - locked with the behavior I described. I dunno. In my mind one of fossil's big advantages is that stays out of your way because it has a limited number of concepts you have to deal with. This leaves your brain free to write code. Absent some stronger argument to the contrary, I'd personally hate to see the devs add a new concept to address your relatively narrow use case. Especially since your new concept has significant semantic overlap with the existing thing, and since getting the behavior you want is pretty darn simple with the existing feature set ... If so, then FWIW the SQLite and Fossil devs deal with this case by merely tagging the version. E.g. released-8.6.1b3 or whatever. You can always get back to that version (fossil update released-8.6.1b3), can always make a new branch from it. My previous post notwithstanding, I agree with Eric. While the ability to close a branch could be used to enforce a policy, my team doesn't even close leaves despite having a similar policy. It's really just that it's never occurred to us we could lock leaves because we've never had a need. Nor have had a need to close a branch. We treat release branches the same as we treat the trunk: Development is done on feature branches, then, after review and approval, merged into the trunk. The trunk isn't locked. Any of us can commit to the trunk at any time. We only do so when a change set has been approved. Same with release branches. ___ 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] What is a baseline?
On Fri, Jul 18, 2014 at 2:40 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Jul 18, 2014 at 8:30 PM, Warren Young war...@etr-usa.com wrote: fossil help timeline talks about a BASELINE. I've discovered by playing that it can be an artifact ID, but I assume there has to be more to it than that, else why use a different term? Neither the Schimpf book nor fossil help really explain the term. It doesn't appear on the documentation index page or in the FAQ. A baseline is a side-effect of fossil's delta manifests. That's a newer and unrelated meaning of the word baseline, that is still meaningful. I think the word baseline in the timeline help comment is the older, obsolete alias for check-in. Originally, fossil required that all files belonging to a give version be included in that checkin's manifest (the official metadata). That proved to be problematic for repos with large numbers (thousands) of files, as it has to record thousands of files in a list when only one changed. List member Joerg Sonnenberg (spelling?) urged Richard to find a solution, and that solution was delta manifests. A baseline is a normal checkin record. A delta manifest is a checkin record which records only files which changed between its own version and the baseline version. Any given non-delta checkin can be a baseline for arbitrary other delta manifests. If a delta gets too big, a new baseline checkin is created with all the files listed in it, and further deltas can be generated from that one. i've got a simple browser which might make this clearer: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest see the Parent/Baseline links, click those, and note the UUIDs. Sometimes the parent and baseline are the same, but not always. Typically any given baseline stays a baseline of its successors until the list of file changes gets to some computed portion of the original file list, at which point it is considered to be too far removed from the current version and a new baseline is created. So, in short: a baseline manifest is simply a checkin record (i.e. manifest) which is _not_ a delta manifest. Whether or not it actually acts as a baseline for any deltas is unimportant (maybe it does not now, but will tomorrow). Can a tag name be a baseline? No - only checkin records can. Originally, checkins were called manifests, but the word manifest now has several meanings. See: http://fossil.wanderinghorse.net/repos/libfossil/doxygen/page_terminology.html i hope that makes some sort of sense. -- - 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 -- 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 2:33 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jul 18, 2014 at 8:23 PM, Ron W ronw.m...@gmail.com wrote:
To get the feature Matt suggested, I suggested adding a new Fossil
defined tag and adding the the following after the code cited above
(inserting the needed conditional in the new if):
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if( /* not creating new branch */ ){
Very elegant :).
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] What is a baseline?
On Fri, Jul 18, 2014 at 8:40 PM, Stephan Beal sgb...@googlemail.com wrote: i've got a simple browser which might make this clearer: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest This one's a good example: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/manifest/98be7a7c10f23ccae709766 the Baseline is actually several versions back from the parent. If you first follow the Baseline link, then go Back and follow the Parent link (a few times), you should see that the next several Baseline links show up as visited, as those versions all share the same baseline manifest. -- - 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 2:23 PM, Ron W ronw.m...@gmail.com wrote:
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if( /* not creating new branch */ ){
I think if you wanted to be pedantic, you should also check to make sure
that the new branch name is not equal to the old branch name. But I almost
feel like I'd be willing to overlook that corner-case
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_BRCLOSED, vid) ){
fossil_fatal(cannot commit into a closed branch);
}
}
___
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] What is a baseline?
On 7/18/2014 12:39, Richard Hipp wrote: We should updates the timeline help to say check-in instead, as that will be clearer to most readers, I think. Sounds good. Baseline appears in the help for /ci_edit /doc /info /zip 3-way-merge ci (as --baseline) descendants merge revert stash tag timeline The help for fossil tag talks about a hexadecimal baseline or artifact ID. Is there a difference? Can a tag name be a baseline? My understanding is that a non-propagating tag is an alias for an artifact ID, and can be used in the same places. True? ___ 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] What is a baseline?
On Fri, Jul 18, 2014 at 2:55 PM, Warren Young war...@etr-usa.com wrote: On 7/18/2014 12:39, Richard Hipp wrote: We should updates the timeline help to say check-in instead, as that will be clearer to most readers, I think. Sounds good. Baseline appears in the help for /ci_edit /doc /info /zip 3-way-merge ci (as --baseline) descendants merge revert stash tag timeline The help for fossil tag talks about a hexadecimal baseline or artifact ID. Is there a difference? Maybe. A check-in is a particular kind of artifact that defines a collection of files that is being checked in as a complete version of the program. An artifact ID can refer to thinks other than check-ins, for example specific versions of files or tickets or wiki pages, etc. In other words, a check-in is always an artifact but an artifact is not always a check-in. Can a tag name be a baseline? My understanding is that a non-propagating tag is an alias for an artifact ID, and can be used in the same places. True? Any tag can be used as a check-in name. It doesn't have to be non-propagating and it doesn't have to be unique. In the event that two or more check-ins both carry the same tag (perhaps because the tag propagates) then the one with the most recent timestamp is selected. ___ 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] committing to a *new* branch from a closed branch not currently possible?
Matt Welland wrote: The scenario I'd like to see supported is roughly as follows: Work on a release is done. The release manager closes the branch so no one can accidentally merge or commit to it. A bug fix is needed. The developer branches off the closed node and fixes the bug and runs QA. The release manager can examine the bug fix, assess the QA results and then open the closed branch, merge the fix and re-close. I think this is a useful release flow. With only slight adjustments, that flow is supported by the tagging scheme that I outlined and that is used to much success and fanfare by the SQLite and Fossil folks, as far as I can tell. It is also supported by doing what you described, and just having your bugfix dev open the leaf before making their new branch. I am starting to wonder whether your issue is primarily around the simplicity (or coarse-grained-ness) of the user authorization primitives in Fossil. For example, perhaps you wish that you could say user A can create check-ins but cannot open or close branches. If so, then it is worth noting a few things about that: (a) Adding your own permission primitive is probably not necessary. If you trust user A to make check-ins, why don't you trust them to open and close branches? (b) If you are only worried about inadvertent check-ins then you can always correct them after the fact. Keep in mind that the branch on which a check-in was made is super easy to change in Fossil. Also, your release manager will be policing these things and will send nasty emails to developers who don't follow the local rules. (c) If you are worried about developers that are so confused that they are doing this often, and your training has consistently failed, and this is causing an overall productivity problem... then fossil is not your primary problem. (d) If, despite all that you, *really* want a new permission primitive, it's probably not too hard to add yourself. And DRH's code is pretty fun to hack against, as many here will attest to. :-) -- Eric A. Rubin-Smith ___ 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] Getting a list of what's changed since the last release
On Fri, Jul 18, 2014 at 2:39 PM, Warren Young war...@etr-usa.com wrote: When I am assembling a new software release, I assemble a ChangeLog from the checkin comments since the last release. Prior to moving to Fossil, I used svn log -r12345:HEAD for this. That lists the checkin comments from r12345 to the current version, only for files in the current directory and below, and only on the current branch. The closest I've come to that so far with Fossil is: $ fossil timeline after 462b6b3bc5 -n 0 Try something like: fossil timeline after | perl -n -e print if /tags: .*branchname/; (Also possible to use awk or sed instead of perl) ___ 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 9:03 PM, Eric Rubin-Smith eas@gmail.com wrote: in Fossil. For example, perhaps you wish that you could say user A can create check-ins but cannot open or close branches. That would break down if someone tried checking in with the --close, --branch, or --integrate options, at least two of which are very useful when working with branches (as many devs prefer to). (b) If you are only worried about inadvertent check-ins then you can always correct them after the fact. Keep in mind that the branch on which a check-in was made is super easy to change in Fossil. FWIW, we've done this in fossil once or twice when the trunk was in a questionable state. (d) If, despite all that you, *really* want a new permission primitive, it's probably not too hard to add yourself. And DRH's code is pretty fun to hack against, as many here will attest to. :-) It would be doable but not be really trivial. Several of the queries make use of the hard-coded list of users, and any number of commands might have to be updated to account for the new permission. -- - 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] What is a baseline?
On Fri, Jul 18, 2014 at 2:55 PM, Warren Young war...@etr-usa.com wrote: Baseline appears in the help for ci (as --baseline) If I understand the description in the help, --baseline forces the created manifest to be a baseline manifest.. This seems reasonable. Perhaps the description can be made clearer? Also, add a description (somewhere) of baseline vs delta manifest. ___ 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] Getting a list of what's changed since the last release
On 7/18/2014 13:05, Ron W wrote: fossil timeline after | perl -n -e print if /tags: .*branchname/; That only works if your commit messages are so short they don't cause a line wrap. I use an 80 column terminal window (old timer, me) so it doesn't take much to cause a wrap. I tried hacking the COLUMNS variable, but that doesn't seem to fool Fossil. (Also possible to use awk or sed instead of perl) Actually, it looks like you've reinvented grep. ___ 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] committing to a *new* branch from a closed branch not currently possible?
Personally I see limited usefulness in closing a leaf. It is branches that need to be closed (albeit by closing a leaf). I'll let the developers that are requesting this know that it ain't gonna happen. As was suggested they can open/re-close the node as needed. On Fri, Jul 18, 2014 at 12:09 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Jul 18, 2014 at 9:03 PM, Eric Rubin-Smith eas@gmail.com wrote: in Fossil. For example, perhaps you wish that you could say user A can create check-ins but cannot open or close branches. That would break down if someone tried checking in with the --close, --branch, or --integrate options, at least two of which are very useful when working with branches (as many devs prefer to). (b) If you are only worried about inadvertent check-ins then you can always correct them after the fact. Keep in mind that the branch on which a check-in was made is super easy to change in Fossil. FWIW, we've done this in fossil once or twice when the trunk was in a questionable state. (d) If, despite all that you, *really* want a new permission primitive, it's probably not too hard to add yourself. And DRH's code is pretty fun to hack against, as many here will attest to. :-) It would be doable but not be really trivial. Several of the queries make use of the hard-coded list of users, and any number of commands might have to be updated to account for the new permission. -- - 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Autosync failed, database is locked
On Fri, Jul 18, 2014 at 12:26 PM, Warren Young war...@etr-usa.com wrote: Actually, I think I just figured it out: $ fossil server /museum # where I keep my *.fossils $ fossil open /museum/repo.fossil $ fossil sync http://me@server/repo ...hack, hack, hack... $ fossil ci Facepalm, right? For those who haven't immediately seen the problem, ci fails because Fossil still knows its DB file is /museum/repo.fossil despite the sync command, but fossil server is also trying to use that same DB file at the same time. Looks like you were asking Fossil to sync one repo against itself. The fix: you really do need a second DB copy to develop against, even when there's a perfectly good copy already on the machine, running underneath fossil server. ci commands against the development copy update the development DB, then autosync merges that change into the copy fossil server is using. My teammates and I have had no problems preforming CLI operations on a repo also be served by fossil server. Before we co-opted our project manager's desk PC to host the main repo, we were sync'ing directly between each other. I didn't run into this before because my Fossil server was remote from the development box, and I never tried fossil open on the server. If the server is intended to host a main repo, then yes, you would want to treat that repo as a separate entity, But, as best I can determine, Fossil won't break anything if you do a CLI commit to a repo being hosted by fossil server. ___ 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] Getting a list of what's changed since the last release
On 7/18/2014 12:44, Richard Hipp wrote: http://www.sqlite.org/src/timeline?a=releaset=trunkn=1000 I think clicking the branch from fossil ui then appending a=AFTERSPEC will work for me: http://server:port/repo/timeline?r=BRANCHNAMEa=AFTERSPEC Today I also learned you can say fossil help /timeline. I didn't expect the HTTP API to be documented. Neat. It would be better if I could do this from the command line, though, so I could pour the text straight into the text editor. Just something for the project wish list. ___ 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] Getting a list of what's changed since the last release
On Fri, Jul 18, 2014 at 3:34 PM, Warren Young war...@etr-usa.com wrote: On 7/18/2014 13:05, Ron W wrote: fossil timeline after | perl -n -e print if /tags: .*branchname/; That only works if your commit messages are so short they don't cause a line wrap. I use an 80 column terminal window (old timer, me) so it doesn't take much to cause a wrap. I tried hacking the COLUMNS variable, but that doesn't seem to fool Fossil. I would have thought Fossil would only wrap lines when STDOUT is a terminal. We actually append our comments to the relevant ticket, so our commit message are just the ticket ID. Each comment appended includes the commit ID. (Maybe we should duplicate the comments in the commits, but we don't) (Also possible to use awk or sed instead of perl) Actually, it looks like you've reinvented grep. Forgot about grep. Most of my non-C/C++ coding is in Perl, so I tend to use that. ___ 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] What is a baseline?
On Fri, Jul 18, 2014 at 3:23 PM, Ron W ronw.m...@gmail.com wrote: On Fri, Jul 18, 2014 at 2:55 PM, Warren Young war...@etr-usa.com wrote: Baseline appears in the help for ci (as --baseline) If I understand the description in the help, --baseline forces the created manifest to be a baseline manifest.. This seems reasonable. Perhaps the description can be made clearer? Also, add a description (somewhere) of baseline vs delta manifest. That use of the word baseline is in accordance with the meaning described by Stephan, not the older obsolete alias for check-in that is written as BASELINE on the timeline help page. Yes, that is confusing. And yes, it needs to be fixed. ___ 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] committing to a *new* branch from a closed branch not currently possible?
Thus said Matt Welland on Fri, 18 Jul 2014 12:41:55 -0700: Personally I see limited usefulness in closing a leaf. It is branches that need to be closed (albeit by closing a leaf). I think this brings up a fine distinction. The behavior of disallowing a descendent checkin applies to a leaf, not a branch. One cannot ``close'' a branch. If you have 3 checkins in a branch and the 3rd is a closed leaf, it is still possible to branch off of both 1 and 2 and checkin those changes as descendents of 1 or 2 respectively. Only descendents of the leaf are not allowed. Branching in Fossil is really just a propagating tag on descendents in the DAG. Andy -- TAI64 timestamp: 400053c97fd8 ___ 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] Autosync failed, database is locked
On Fri, Jul 18, 2014 at 3:58 PM, Warren Young war...@etr-usa.com wrote: It may be that SQLite has changed the way it does locking since you tried this. Different OSes also affect the way SQLite does locking. Most of us are running fossil server even though we no longer do peer-to-peer sync. We're running Fossil 1.27, most of us on Debian Stable, 2 on MS Win7 Pro. We run fossil server instead of fossil ui so we can have remote access to the UI. I suspect that doing a commit while a sync was in progress would result in warnings. Never tried to do that. Apparently, we were lucky enough that commits never collided with syncs. ___ 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] Autosync failed, database is locked
Thus said Warren Young on Fri, 18 Jul 2014 13:58:38 -0600: It doesn't completely fail. The checkins do occur; fossil just gripes about it. (This might be the autosync retry feature at work.) No, autosync only tries once by default in each direction (pull/push)---the same as it has always done---and the output from the failed autosync showed no indication that it had been altered it from the default (so it wasn't the ``autosync retry feature'' at work in this case. :-) Andy -- TAI64 timestamp: 400053c98147 ___ 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] Getting a list of what's changed since the last release
[Default] On Fri, 18 Jul 2014 13:34:26 -0600, Warren Young war...@etr-usa.com wrote: On 7/18/2014 13:05, Ron W wrote: fossil timeline after | perl -n -e print if /tags: .*branchname/; That only works if your commit messages are so short they don't cause a line wrap. I use an 80 column terminal window (old timer, me) so it doesn't take much to cause a wrap. I tried hacking the COLUMNS variable, but that doesn't seem to fool Fossil. That was solved some time ago: fossil help timeline : -W|--width num Width of lines (default is to auto-detect). Must be 20 or 0 (= no limit, resulting in a single line per entry). (Also possible to use awk or sed instead of perl) Actually, it looks like you've reinvented grep. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Groet, Cordialement, Pozdrawiam, Regards, Kees Nuyt ___ 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] committing to a *new* branch from a closed branch not currently possible?
2014-07-18 20:53 GMT+02:00 Richard Hipp d...@sqlite.org:
On Fri, Jul 18, 2014 at 2:23 PM, Ron W ronw.m...@gmail.com wrote:
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if( /* not creating new branch */ ){
I think if you wanted to be pedantic, you should also check to make sure
that the new branch name is not equal to the old branch name. But I almost
feel like I'd be willing to overlook that corner-case
I interpret this message as:
http://fossil-scm.org/index.html/info/2b79c600d5
Personally, I never needed the use-case described
by Matt Welland, but it sounds reasonable. My opinion
is that if it doesn't sacrifice fossil's main principles
(e.g. least-surprise), why not.
Regards,
Jan Nijtmans
___
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] committing to a *new* branch from a closed branch not currently possible?
Thus said Jan Nijtmans on Fri, 18 Jul 2014 23:58:09 +0200: I interpret this message as: http://fossil-scm.org/index.html/info/2b79c600d5 What if I do: fossil up closedbranchname fossil ci --branch closedbranchname Andy -- TAI64 timestamp: 400053c99bca ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] newbie questions
Hi Folks, Just starting to play with Fossil. Installed it on my laptop, but the install instructions on the wiki include this statement: Released versions of fossil come with pre-compiled binaries and a source archive http://www.fossil-scm.org/download.html for that release. Which seems to imply that the binary I just installed includes the Fossil source tree. Damned if I can find it though. Related question: Is there a way to tell what options were invoked when a binary version was compiled? (Particularly interested in knowing if the json API is enabled by default -- looking at using Fossil as a self-contained note-taking application, and using a couple of pages of Javascript as a front-end, that I just stick in the database - voila, self-contained webapp and back-end - somewhat like a CouchApp for those familiar with CouchDB). Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 5:58 PM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2014-07-18 20:53 GMT+02:00 Richard Hipp d...@sqlite.org:
On Fri, Jul 18, 2014 at 2:23 PM, Ron W ronw.m...@gmail.com wrote:
/*
** If not creating a new branch, do not allow a commit against a
closed
branch
*/
if( /* not creating new branch */ ){
I think if you wanted to be pedantic, you should also check to make sure
I interpret this message as:
http://fossil-scm.org/index.html/info/2b79c600d5
Also, I had suggested separate tests for closed leaf and closed branch.
Otherwise, this looks good.
___
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] committing to a *new* branch from a closed branch not currently possible?
2014-07-19 1:02 GMT+02:00 Ron W ronw.m...@gmail.com: Also, I had suggested separate tests for closed leaf and closed branch. Fossil doesn't have the concept of a 'closed branch', it's only the final leaf that can be closed. So I really don't know how to implement that. Regards, Jan Nijtmans ___ 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] newbie questions
Thanks! Jan Nijtmans wrote: 2014-07-19 0:15 GMT+02:00 Miles Fidelman mfidel...@meetinghouse.net: Hi Folks, Just starting to play with Fossil. Installed it on my laptop, but the install instructions on the wiki include this statement: Released versions of fossil come with pre-compiled binaries and a source archive http://www.fossil-scm.org/download.html for that release. Which seems to imply that the binary I just installed includes the Fossil source tree. Damned if I can find it though. The binaries and the source archive are separate downloads. Related question: Is there a way to tell what options were invoked when a binary version was compiled? $ fossil version -v This is fossil version 1.30 [13f8ba6ca8] 2014-07-18 22:03:48 UTC Compiled on Jul 19 2014 00:34:26 using gcc-4.8.2 (64-bit) SQLite 3.8.6 2014-07-01 11:54:02 21981e3506 Schema version 2011-04-25 19:50 zlib 1.2.8, loaded 1.2.8 SSL (OpenSSL 1.0.1f 6 Jan 2014) TCL (Tcl 8.6.0, loaded TH_OK: 8.6.1) USE_TCL_STUBS TCL_PRIVATE_STUBS JSON (API 20120713) Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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] committing to a *new* branch from a closed branch not currently possible?
On Fri, Jul 18, 2014 at 7:12 PM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2014-07-19 1:02 GMT+02:00 Ron W ronw.m...@gmail.com:
Also, I had suggested separate tests for closed leaf and closed branch.
Fossil doesn't have the concept of a 'closed branch', it's only
the final leaf that can be closed. So I really don't know
how to implement that.
How about, defining a new branch closed tag and add:
/*
** If not creating a new branch, do not allow a commit against a closed
branch
*/
if(!sCiInfo.zBranch){
if( db_exists(SELECT 1 FROM tagxref
WHERE tagid=%d AND rid=%d AND tagtype0,
TAG_BRCLOSED, vid) ){
fossil_fatal(cannot commit into a closed branch);
}
}
(Yes, I know are more details, but this is the general idea)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
