2013/7/22 Stephan Beal <sgb...@googlemail.com> > On Mon, Jul 22, 2013 at 6:15 PM, Jacek Cała <jacek.c...@gmail.com> wrote: > >> >>> i am assuming by "each repo" you mean "each clone" (which is also "each >>> repo"). If that is the case, i can conceive of this working strictly >>> locally, but i still don't see how it can possibly scale if those numbers >>> propagate in any way. If i clone the repo 100 times, do i end up with 1.1 >>> ... 1.100 ? >>> >> >> Yes, that would only mean that your clone tickets will start with >> '1.100-...' but it doesn't affect clone '1' much. All tickets of '1' are in >> form of '1-n' >> > > There's the rub. For that to happen, the number needs to be save in the > repo, which requires write access to the repo for anyone who can clone (and > guest can clone from most repos). That alone is a potential hole which more > security-conscious people wouldn't tolerate. If some malicious **** ran > this from 10 shells: > > # while true; do rm -f clone.fsl; fossil clone http://.... clone.fsl; done > > and let it run for a few days, he's just screwed up my numbering so bad > that i probably won't want to use sequential numbering anymore. It's not > helpful if my numbers are 8 digits long. >
Certainly, true... but you can think about a 'superclone' that has the mentioned feature (with access restrictions), whereas the standard clone operation would initialize the cloned repo with some random seed not changing the parent. And even with random seeds you would still have a nice ticket numbering within your clone. Generally, I found not having human readable tickets numbers so difficult that I used to embed some sort of identifiers within the ticket name (not scalable at all :-( Cheers, Jacek
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
