[fossil-users] close last leave on a branch and it disappears
Because of the discussion about many branches and using private branches for development, I was experimenting (on a copy) and closed the leave on the windowscompilers branch and the trunk. Instantly they disappear from branches. For the windowscompilers branch I was glad, I was, initally, disappointed in case of the trunk. Luckily you can do shun and the trunk is back again. In the end the trunk is just an other branch, nothing special! So the behaviour is fine (with me). Richard, if you got the time and it fits with your philosophy then by all means close the windowscompilers branch since it has fulfilled it's purpose. At least one branch less to clutter the display! -- Rene ___ 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] More consideration for the local changes
2011/2/11 Lluís Batlle i Rossell virik...@gmail.com: I think the approach taken by most VCS I've seen is far better than what fossil provides now: leave the conflict files in the working directory with a different name, like it could be src/update.c.conflict for example. Yes, something like that. As I recall, SVN update leaves a file with .rNN as the extension, where NN is the revision number, and another file with the trial merge, while leaving the local copy as-is. (Of course, using the revision as a file extension does not work well with most DVCSs.) As I understand now, I've either to use the stash or commit somewhere and try the operations susceptible of file merges (update/merge) always with a working directory clean of changes. I personally dislike having to have this care. Any thoughts? Agreements? Disagreements? I agree, a VCS - any VCS - should not overwrite or delete local changes - or anything unmanaged. That said, I long ago learned (the hard way) the first axiom of version control: A VCS is not a backup system. So, I do make backups before I update my local working copies. Hopefully, nothing goes wrong and do not need to restore anything from a backup. But please, do provide better handling of local changes and unmanged files. (And of course I'm writing this after just having lost some lines of code) I know what you mean. No matter how often you make backups, once in a while you wish you made them more often. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ticket opened date
According to the documentation, tickets consist of a series of
artifacts, each with its own time stamp, the most recent providing the
value of mtime. Is there a way to get the timestamp of a ticket's
first artifact?
Alternately, I tried adding an opened field to the ticket table
schema. In the New Ticket screen, I tried adding:
set opened [ expr { clock format %Y-%m-%d -gmt 1 } ]
but the TH1interpreter did not like this (nor several variations that I tried).
I have searched for and read through several TCL references, but they
have been of limited help. Are there good references any one here
cares to recomend?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
