Yea I wasn’t meaning to say RCS is better, or I would be using it. I’m using fossil because it is so complete and a variety of reasons is far surpasses RCS. Just saying I miss that feature and looking for a work around. That particular feature of RCS is very handy for situations where you have standalone scripts or things that are updated often and distributed. Aside from manually updating a number right before commit, I don’t know how else I could keep track of what versions of the script are floating around. IN a larger project where you have one big release, it makes sense to use a master version file and bake it into binaries, etc.. but for scripts..well..sure…I could have a make step to always build scripts into distributed scripts that have versions baked in somehow…but that is a pain when you’re talking about a lot of totally independent scripts that are updated often and independently of each other.
So one quick question…is a hash created only during commit? doesn’t happen yet during “add” right? I always forget, when you’re talking about “checkin” are you referring to stuff that has been added or stuff that has been committed? I forget what is the notion of “checkout" or “checkin" in fossil. Time to go re-learn some concepts again…. I hear what you’re saying that, if I commit a file to get the hash, then update the source to have the new hash, the file then appears as having been “changed”. Its not clear to me it would continue to be part of the next checkin though unless it is added again? Its just that the file in place would be showing as having changed compared to the repository, due to the version being updated in there. > On Aug 15, 2017, at 12:18 PM, Stephan Beal <sgb...@googlemail.com> wrote: > > > > On Tue, Aug 15, 2017 at 8:09 PM, Steve Schow <st...@bstage.com > <mailto:st...@bstage.com>> wrote: > well I’m hoping to have a version that is stamped into the comments of the > actual file as well. > > Stamping that version would change the hash. To the best of my knowledge that > feature cannot be implemented with DVCS (which requires hashing (non-serial > IDs) for versioning). > > For example I have some javascripts that are used in another entirely closed > environment that doesn’t have access to fossil, so it would be nice to be > able to know which version of the script is being used…with many updates > happening in early stages of development, its easy to forget to manually > update a comment with a number. > > For those types of things you've got to "build" a version of those scripts, > injecting the current version number. > > what I miss about RCS, is it would bump up the RCS number and could > substitute that into the source for me during checkout. > > But RCS was missing about 99% of the features of a modern DVCS (and RCS > didn't have the "D" at all). > > It sounds like what I would need to do is keep a seperate db that associates > hashes with version numbers and then use a wrapper script or something to do > this work of substituting that into the source comment. yes? > > Right. But the moment you do that, you change the hashes of those files, > making them completely different content as far as any DVCS is concerned. > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > <http://wanderinghorse.net/home/stephan/> > "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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
