working on multiple projects

[Weiss]

need some hints on what would be a good strategy, or set of rules maybe, when you have to work on multiple projects in same  time. Some projects are spinoffs and involve heavy modifications to existing units. Some, when they mature, will be of a good use to existing applications. Also, I find that I have to switch between machines.

Currently everything is a bit messy, modified code under same name, different copies on sticks and machines. Please share your good habits, I have no mentor, just you fellas.

[cdbc]

Hi
I use Gitlab, just like fpc & lazarus.
It doesn't matter which machine I'm on, I just pull from origin and have the same codebase, wherever I go...
Regards Benny

[Martin_fr]

In the IDE, install package Project-Groups. That allows to easily switch between projects. (and you can also add package, that you need to open often).

Then it depends, do you have different project (lpi) for each of your work items? Or do you have one project, and change (copy outside the IDE) units on disk?

Ideally, any unit that may be part of more than one project => move to a package (or have several packages).

If absolutely needed, for small changes within a unit, you can use IFDEF. But may better use patterns like "dependency injection".


For all else, use GIT (you do not need an account on any online git provider / it works all local).

If you do need several slightly different versions of the same unit => you can use branches in git, to keep each versions. Between the branches you can merge and/or cherry-pick. So new code can be added to all branches.

It also means, you can roll back if you made an error. You still have access to all older versions of the file.
(You can even make a commit every 5 to 10 minutes while working, and when all is done combine those few dozen commits into a single commit to keep for long time history.

Git also helps synchronizing.

You can synchronize several folders on one machine. And synchronize between several machines.

- Any git repo can have any other folder on your PC as "remote" => so you can push and pull between folders.
- A git repo (one single one) can have several "worktree"s, very similar to the above but no push/pull needed.

And you can have other computers push/pull. Either via shared folders, or by running "git daemon" and allow network access.

And you can backup your repo to a private github/lab/... repo.
(Any git repo can have many remotes)


Depending on what you need, more details on request.

[Martin_fr]

My setup for working on Lazarus:

On my main PC
- git clone of official repo
  - multiple worktree, so I have fixes, main and custom checkout if needed
  - also connected to private fork on gitlab (for backup)
- 2nd git clone of official repo
  - also connected to forks of some contributors
     Those forks show up in "git logs", I don't want that in my above main clone. Thus a 2nd clone
  - also connected (as client) to the above main clone. So I can "move" stuff between them)
- 3rd clone on different disk
   This is only connected to the above (top) main repo.
   This is a backup. It regularly pulls all changes. So if I make a commit, even if I do not push it, it gets backed up locally onto a different disk

Several Virtual Machines
- each with a clone that is connected to
  - official remote repo
  - above main (so I can "Move" changes, without a need to push them)
     either via git daemon or shared folder
  - other remotes as needed

My Laptop
- Same as the VM.

The order of connection (which repo is remote or client of which other) matters, in terms of what shows in the logs.
A client can show all the remote branches of remotes it is connected (and will have them in "git log --all", which may sometimes be to much)
A remote does not have access to what clients have on top of what the pulled.
So depending what branches I want to see in which repo, dictates in which direction I connect them.

I have many dozen private local branches.

- Some just contain a commit that adds a "TODO" comment.
- Others have work I started, and plan to finish some day.
- Yet others have work I started, and then decided for a different approach (yet I still keep the old "failed" approach, if ever I wonder what I did back then)

[ALLIGATOR]

Another good thing about git is - submodule

[TRon]

Use at least a vcs, whichever one floats your boat.

I use git myself, it allows for working on different branches of the same base-code (such as per your example).

It is pretty easy to setup your own "host" if wanted or stuff things to whatever storage device if wanted but as already mentioned by other use one of the available hosters.