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 wrote: > 2014-07-19 1:02 GMT+02:00 Ron W : > > 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 >

Re: [fossil-users] newbie questions

Thanks! Jan Nijtmans wrote: 2014-07-19 0:15 GMT+02:00 Miles Fidelman : 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

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

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 wrote: > 2014-07-18 20:53 GMT+02:00 Richard Hipp : > > On Fri, Jul 18, 2014 at 2:23 PM, Ron W wrote: > >> /* > >> ** If not creating a new branch, do not allow a commit against a > closed > >> branch > >> */ > >> if( /* not creating new branch */

Re: [fossil-users] newbie questions

2014-07-19 0:15 GMT+02:00 Miles Fidelman : > 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

[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 for that release." Which seem

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: > What if I do: fossil up closedbranchname fossil ci --branch closedbranchname Andy -- TAI64 timestamp: 400053c99bca __

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 : > On Fri, Jul 18, 2014 at 2:23 PM, Ron W 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 t

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

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 i

Re: [fossil-users] Autosync failed, database is locked

On Fri, Jul 18, 2014 at 3:58 PM, Warren Young 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 F

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

Re: [fossil-users] What is a "baseline"?

On Fri, Jul 18, 2014 at 3:23 PM, Ron W wrote: > On Fri, Jul 18, 2014 at 2:55 PM, Warren Young 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.. > >

Re: [fossil-users] Autosync failed, database is locked

On 7/18/2014 13:43, Ron W wrote: Looks like you were asking Fossil to sync one repo against itself. Yes. My teammates and I have had no problems preforming CLI operations on a repo also be served by "fossil server". It doesn't completely fail. The checkins do occur; fossil just gripes ab

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

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=release&t=trunk&n=1000 I think clicking the branch from fossil ui then appending &a=AFTERSPEC will work for me: http://server:port/repo/timeline?r=BRANCHNAME&a=AFTERSPEC Today I also learned you can say "fossi

Re: [fossil-users] Autosync failed, database is locked

On Fri, Jul 18, 2014 at 12:26 PM, Warren Young 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

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,

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 h

Re: [fossil-users] What is a "baseline"?

On Fri, Jul 18, 2014 at 2:55 PM, Warren Young 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 clea

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

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

Re: [fossil-users] What is a "baseline"?

On Fri, Jul 18, 2014 at 8:55 PM, Warren Young wrote: > > 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? Sorry, i understood "be" a baseline as "be-a baseline." A tag may of cou

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

Re: [fossil-users] What is a "baseline"?

On Fri, Jul 18, 2014 at 2:55 PM, Warren Young 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 >

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

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

Re: [fossil-users] What is a "baseline"?

On Fri, Jul 18, 2014 at 8:40 PM, Stephan Beal 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/manifes

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 wrote: > On Fri, Jul 18, 2014 at 8:23 PM, Ron W 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):

Re: [fossil-users] What is a "baseline"?

On Fri, Jul 18, 2014 at 2:40 PM, Stephan Beal wrote: > On Fri, Jul 18, 2014 at 8:30 PM, Warren Young 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 diffe

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

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 wrote: > Here's how we do it for fossil releases: > > http://www.fossil-scm.org/fossil/vdiff?from=release&to=trunk&detail=1 > Correction: that's the diff for that range. Richard's solution gives you the commit comments. -- - stephan beal http:

Re: [fossil-users] committing to a *new* branch from a closed branch not currently possible?

On Fri, Jul 18, 2014 at 8:34 PM, Matt Welland wrote: > I think this is a useful release flow. > Yes, but... because a given release has a unique UUID (or a non-propagating tag), the QA guys can work from that without worry about someone accidentally moving their target out from under them (espec

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 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=release&t=trunk&n=1000 http://www.fossi

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

Re: [fossil-users] What is a "baseline"?

On Fri, Jul 18, 2014 at 8:30 PM, Warren Young 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 reall

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 wrote: > "fossil help timeline" talks about a BASELINE.

[fossil-users] Getting a list of what's changed since the last release

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

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

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

[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

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 wrote: > > On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland 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 >

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 leave

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 wrote: > Stephan Beal wrote: > > > On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland > 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 allowe

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

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

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 h

[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

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

Re: [fossil-users] libfossil: new script binding

On Fri, Jul 18, 2014 at 3:27 PM, Stephan Beal 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 t

Re: [fossil-users] Autosync failed, database is locked

On Fri, Jul 18, 2014 at 11:25 AM, Warren Young 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 >

[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: ec88709387828f

Re: [fossil-users] libfossil: new script binding

On Thu, Jul 17, 2014 at 8:38 PM, Stephan Beal 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://fossi

Re: [fossil-users] creation-date of files/subdirs in a dir, from command-line

On 18 July 2014 12:20, Stephan Beal wrote: > On Fri, Jul 18, 2014 at 12:14 PM, Michai Ramakers > 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 S

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

Re: [fossil-users] creation-date of files/subdirs in a dir, from command-line

On 18 July 2014 12:14, Michai Ramakers 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.

Re: [fossil-users] creation-date of files/subdirs in a dir, from command-line

On 18 July 2014 12:14, Michai Ramakers 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 htt

[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