FHS location for development files

[Tony0945]

Everything in the File Hierarchy Standard seems to be for files that have already been distributed. Where do you store files on projects under active development but not released?

I've been using /home/{developer name} but that's a little messy and a mistake in where one is can wipe out non-related files. I've thought of /home/{project name}, making the project name an actual user and logging in with the project name, but that seems to be a perversion of the user system. One feature of this is that the password can be shared if there is more than one developer. Another is that a mistake in a command or script (think rm -r *) can only destroy files owned by the project. Users can su into the project and su - brings them right into the project directory. Downside is leaving all those users around as projects and polluting /etc/group.

I just thought of another scheme. If /mnt/projects is mounted on a central drive partition, /home/{project-name} can be a symlink to a sub-directory on /mnt/projects. This avoids having multiple different copies. Every time you log in, from whatever workstation, you get the same files. Haven't thought that through.

What are your thoughts and practices?

[NeddySeagoon]

Tony0945,

Use a version control system of your choosing.
Check things in, check things out.

The repo can even be on a remote system.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Tony0945]

Ah, but where do I check them into? A year or two ago, I struggled to make a git repo. With a lot of help here I managed. I've since converted it to rsync which is much simplere.

Last real VCS I used was ClearCase. Probably before a few forum members were born.

[miket]

When you wrote about how you "struggled to make a git repo" and then talked about rsync, I can only conclude that you're talking about having made changes to how you deal with the Portage tree. In general, a typical Gentoo user who uses git only to fetch the tip of the ebuild repository is taking advantage of pretty much only one git feature: cryptographically signed commits. This is a protection against having bad actors insert malicious changes into the ebuilds before they reach you, but it's a long way from using the full power of git.

ClearCase is a traditional client/server version-control system. That means that any changes you make have to be committed to the server ir order to take effect. The development cycle includes the steps of pulling the most recent version from the repository on the server and then committing any of your changes back to that same server-side repository. Subversion and CVS work that same way. You would work on your projects under whatever directory you'd choose under your own home directory but that directory tree would reflect the layout of the project in the repostory on the server. All the project history resides on the server. If you ask for something like a log of a diff, the ClearCase client has to request that data from the server. The big downside is that even if all you want to track is a private little project, in order to have it under version control with ClearCase you must set up (or have an administrator set up) the repository on the server.

Git is an example of a newer kind of version-control system: a distributed version-control system. Every checkout contains (within a hidden directory) the complete project history. It is possible to use it without setting up a central repository. If you have a really small personal project (or say a tree you want to keep in version control--like your /etc directory), you can skip any kind of central repository. If you like, you can set up a centralized repository somewhere on your network or use a hosting service like GitHub, but you don't have to. If you do have such a central git repostory for your project, using git will feel rather like using ClearCase because you're still pushing changes to the server, but the git difference is that whole repository history is local to your checkout.


Let me reiterate an important point: regardless of the type of VCS, one principle is that development happens in a directory under your home directory. True, is is fairly common for the root directory of a project to have a fixed name, but this directory does not have to be a direct child of $HOME. So, say you're starting a C project called fastchomp, a PHP project called webwand, and a Go project called golly. The three project directories could just as well be arranged under your home directory like this:

[Tony0945]

Thank you for your long and detailed reply.

[John R. Graham]

[Tony0945]

Thank you, both of you offering good information, but both are missing my main question "What is your working area on your local machine?" i.e. when you do your git-clone, where in the file hierarchy are they? Maine are in /home/tony/projects/{projectname}/{projectname-version} where they can be conveniently be tarred up and moved to the distfile server. So the actual source directly is usually home/tony/projects/{projectname}/{projectname-version}/src which is way too deep. The xterm prompt covers half the line. yes, I could change the prompt and then forget where I am amongst all the open terminals and accidentally delete something or many somethings. and I have.

[John R. Graham]

Well that's easy. ~/Projects/ProjectName. But you can (and should) use any hierarchy you like within your home directory. It doesn't need to be standardized. You don't create a ProjectVersion sub-structure because version control handles that without additional subdirectory depth. If you want more details, let me know.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[John R. Graham]

[Hu]

Regarding prompt depth, I like using a prompt that expresses $HOME as ~, so instead of /home/hu/projects, I just get ~/projects in my prompt. When I go outside home, it switches to a more verbose path (though even there, I usually let it trim some context and keep the full path in my statusline).