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
