There are lots of docs on the fossil page, am I just supposed to checkout the whole repository to view them offline?
The man-pages are rather sparse, and unlike in git, there seem to be no meta-manpages encompassing topics covered in the online documentation, such as https://fossil-scm.org/home/doc/trunk/www/globs.md.
(A long-time fossil contributor here...)
Fossil, as it has always been distributed by the Fossil project, is only a single binary, not a bundle with the docs. Getting offline access to all of the docs requires cloning the repository:
fossil clone https://fossil-scm.org/home fossil.fossil
but it doesn't require checking out the repository. After cloning, do:
fossil ui fossil.fossil
And you'll have all of the docs at your fingertips. That documentation is intended to be viewed from within fossil, e.g. it uses fossil-specific markup, so providing it under, e.g., /usr/share or some such would not be terribly helpful.
The majority of day-to-day usage questions can be answered via the built-in help command, but the slew of documentation we maintain is far too large to include in the fossil binary.
The fossil man page is essentially just a stub for the benefit of Linux distributions which require one for binaries included in their package databases, noting that that's not something we do within the fossil project: all such packages are maintained by independent third parties.
Edit: for future reference: you'll get more much timely responses over in the fossil's own forum (just follow the forum link on the home page). Posting may be done anonymously, it doesn't require creating an account, but anonymous posts must await approval from a moderator.
Related
Are there best-practice guidelines for maintaining a GitHub repository? I've contributed to many open source projects and used GitHub for projects that I work on solo, but now I'm working with a team of six developers, including myself, to build a system, and I've been placed in charge of maintaining the repository. Nothing is to get merged into our main branch without my approval. As little as I know about maintaining a GitHub repository, of those within the organization (two team members are consultants) I've the most experience with the process.
But I've never maintained a GitHub repository, and while I'm doing OK, I know that there must be a body of knowledge out there of how to handle this correctly. I just haven't been able to find it.
One hurdle I've been jumping over repeatedly, for example, is merge conflicts. Usually they're minor, but not always. Is there some known system available that allows me to enforce who has the ability to edit which files at any given time, for example?
And yes, I realize this may not be the best Stack Exchange forum, but none of the others seemed more suited to the topic.
The Cloud Native Computing Foundation (CNCF) serves as the vendor-neutral home for many of the fastest-growing open source projects, including Kubernetes, Prometheus, and Envoy.
As such, it can be used as a starting point for your own project: see contribute.cncf.io/maintainers/github/, which offers:
template, to be usre you have your README, LICENSE and other important files.
labels, to better classify your issues
Add also a clear "release and maintenance policy", and you should be in good shape.
Is there any distributed version control system capable to grant Read/Write access to users with sub-folder granularity level?
i.e. if I want to give access to /foo tree for UserA, and only to /foo/bar for UserB?
UPD as far as I understand, this is impossible for Git (it treats repository as a whole only). What about Bazaar and Mercurial?
UPD still looking for a better answer.
EDIT: Just checked the comments, OP is looking for both read/write access, hence retracting this answer.
Nope, its not impossible for Git. The Gitolite project is very mature and has provided fine-grained access permissions (repo/branch/directory/file level permissions) for many years.
A specific example on restricting changes to a single file is found here: http://gitolite.com/gitolite/vref.html#NAME
A few simple examples are here, and more detailed documentation on defining rules is also available here.
Edit: Added another link
A write protection can be added to Mercurial, Subversion or git by using SCM-Manager and the Path Writeprotect Plugin. You can define a path and users or groups with write access to it.
As #maxim1000 noted in a comment, the best way to accomplish this may be to run a Subversion server, which can do fine-grained access control for both reads and writes, on a per-path and per-branch basis. If users want the power of a DVCS client, they can then use git svn or hg svn to import the portions of the repository to which they have access into DVCS and interact accordingly. It should even be possible for someone with higher access to merge changes to a subtree from someone with lower access without losing the excellent merge tooling that the DVCS implementations provide.
(Not sure if this is the best SE, but nothing else seemed close enough)
I'm a 'fresh' PhD Researcher, and after chatting with most of my cluster-colleagues (including staff), I suggested putting together a system for sharing 'acquired experiential knowledge' (Digital Communications within Electrical Engineering, so lots of code, lots of languages, and lots of algorithms, therefore a lot of things to 'work out' twice.)
Any time that I've done major coding projects, it's been a single repository containing a single project, and this seems to be the general state of 'HOWTO' articles in this area. I'd be looking to put something together that would have a wiki 'front end' (I've got experience with Mediawiki so I will probably stick with that), with 'context' info and theoretical stuff, with a VCS 'backend' that would hold archives of code-bases that people wanted to share. The reasoning for this archive is that there is a lot of person-turnover and any generated code can disappear into the ether on their departure, so that experience is lost.
Can anyone recommend any tools for this kind of multi-project VCS backend? Ideally I'd like something similar to bitbucket but locally served.
If you want it open, code.google.com is a possible solution
For self-hosting Git repositories, and fronting them with something like Gitweb, Gitolite is the current standard. Your wiki can then provide links to both gitweb and the actual repository URLs. Keep to the 'one repository per project' structure. Any cross-referencing (say by language, topic, and task) can happen in the wiki.
That sounds like a problem, which could be solved by using github or bitbucket. Both offer (distributed) VCS with a wiki and an issue tracker. Github using Git and bitbasket using Mercurial. You can even make everything private.
I recently joined a project team that is using TFS (I have happily avoided TFS until now). I am trying to determine if there is a way to require a story/defect reference to be associated with every commit comment?
With Tortoise/SVN it was easy to add a requirement for a reference number to be required with each commit. Personally, I like to track every commit back to a user story or defect, so I am hoping there is a way make this mandatory in TFS as well? I searched SO and Google, and haven't found the magic "key words", so if someone can point me in the right direction, it would be greatly appreciated.
Note: Stories and Issues are stored in other tools and not tied to TFS in any way.
Can it be done? Yes. Is it easy? Fairly easy. However, two caveats. Caveat number one: you're going to have to write code. Codeplex has some good examples here. Additional searches on codeplex and on the almighty Google will locate you more examples.
The big caveat here is that check-in policies are client-side. Once you develop the policy, it will need to be deployed to all developer workstations. If the policy isn't installed? It is ignored. While I'm a big fanboy of TFS, this is one oversight that I can't believe is still in place after three major version releases.
You could create a server-side check-in monitor that examines the check-in and determines if the story has been associated. However, it will not prevent the check-in, but you can use it to alert someone to resolve it after the fact.
Switch to a DVCS system like Git (see this article on pre-commit hooks) or Mercurial (see this other article on pre-commit hooks) which DO have server-side hooks that can be overridden to do validation checks. :-)
Yeah, I know, not really the answer you were looking for but it is an alternative solution to the problem that some other SO users might find useful.
With the DVCS type of system, you can have a separation between hooks that run on the local computer and hooks that run on the server when your commit is pushed back to the shared repository. That kind of concept does not have a corollary in TFS. It can make some things easier for your developers. For example, every changeset that was committed to our shared repository had to have a ticket number attached in the commit message. Local pre-commit hooks guarded against changesets getting created (in Mercurial) that did not have proper commit messages.
With TFS's support for GIT in an upcoming release maybe things will be easier in this regard.
I just read Spolsky's last piece about Distributed vs. Non-Distributed version control systems http://www.joelonsoftware.com/items/2010/03/17.html. What's the difference between the two? Our company uses TFS. What camp does this fall in?
The difference is in the publication process:
a CVCS (Centralized) means: to see the work of your colleague, you must wait for them to publish (commit) to the central repository. Then you can update your workspace.
You are an active producer: if you don't publish anything, nobody sees anything.
You are a passive consumer: you discover new updates when you refresh your workspace, and have to deal with those changes whether you want it or not.
.
a DVCS means: there is no "one central repository", but every workspace is a repository, and to see the work of your colleague, you can refer to his/her repo and simply pulled its history into your local repo.
You are a passive producer: anyone can "plug in" into your repo and pull local commits that you did into their own local repo.
You are an active consumer: any update you are pulling from other repo is not immediately integrated into your active branch unless you explicitly make it so (through merge or rebase).
Version Control System is about mastering the complexity of the changes in data (because of parallel tasks and/or parallel works on one task), and the way you collaborate with others (other tasks and/or other people) is quite different between a CVCS and a DVCS.
TFS (Team Foundation Server) is a project management system which includes a CVCS: Team Foundation Version Control (TFVC), centered around the notion of "work item".
Its centralized aspect enforces a consistency (of other elements than just sources)
See also this VSS to TFS document, which illustrates how it is adapted to a team having access to one referential.
One referential means it is easier to maintain (no synchronization or data refresh to perform), hence the greater number of elements (tasks lists, project plans, issues, and requirements) managed in it.
Simply speaking, a centralized VCS (including TFS) system has a central storage and each users gets and commits to this one location.
In distributed VCS, each user has the full repository and can make changes that are then synchronized to other repositories, a server is usually not really necessary.
Check out http://hginit.com. Joel wrote a nice tutorial for Mercurial, which is a DVCS. I hadn't done any reading about DVCS before (I've always used SVN) and I found it easy to understand.
A centralized VCS (CVCS) involves a central server that is interacted with. A distributed VCS (DVCS) doesn't need a centralized server.
DVCS checkouts are complete and self-contained, including repository history. This is not the case with CVCS.
With a CVCS, most activities require interacting with the server. Not so with DVCS, since they are "complete" checkouts, repo history and all.
You need write access to commit to a CVCS; users of DVCS "pull" changes from each other. This leads to more social coding facilitated by the likes of GitHub and BitBucket.
Those are a few relevant items, no doubt there are others.
The difference is huge.
In distributed systems, each developer works in his own sandbox; he has the freedom to experiment as much as he want, and only push to the "main" repository when his code is ready.
In central systems, everyone works in the same sandbox. This means that if your code is not stable, you can't check it in, because you will break everyone else's code.
If you're working on a feature, it will naturally take a while before it stabilizes, and because you can't afford to commit any unstable code, you would sit on changes until they're stable. This makes development really really slow, specially when you have lots of people working on the project. You just can't add new features easily because you have this stabilization issue where you want the code in the trunk to be stable but you can't!
with distributed systems, because each developer works on his own sandbox, he doesn't need to worry about messing up anyone else's code. And because these systems tend to be really good at merging, you can still have your codebase be up to date with the main repository while still maintaining your changes in your local repository.
I would recommend reading Martin Fowler's review of Version Control Tools
In short the key difference between CVCS and DVCS is that the former (of which TFS is an example) have one central repository of code and in the latter case, there are multiple repositories and no one is 'by default' the central one - they are all equal.