tsrc
tsrc copied to clipboard
your-tools
Allow absolute path and variables in 'src'
An improvement would be to allow absolute path and variables in 'src' such as : src: /home/xxxx/things/project src: ~/things/project src: ${MY_PRJPATH)/${OTHER_VAR}/subproj
On complex project this allow some kind of customisation using environnement variables and easy shareable between developpers.
I think this is a dangerous idea.
What if the absolute path does not exist ? What if the path is already used by an other manifest ? What if the environment variable does not exist ?
Maybe what you need is a script that runs tsrc in the correct place instead ...
Just to answer to questions above: What if the absolute path does not exist ? -> error and abort
What if the path is already used by an other manifest ? -> don't care and update if sync is called, signal deltas on status if delta are detected (fixed-ref given in manifest does not match, dirty, ...)
What if the environment variable does not exist ? -> error and abort
Maybe what you need is a script that runs tsrc in the correct place instead ... The idea is to avoid copy/clone same repository between several project.
There are implementation details that make it hard to implement these features.
For instance, you'll need to find the manifest clone path from any repository.
Right now we do that by looking for the .tsrc hidden repository somewhere in the parent directories.
This won't work well if the manifest contains absolute paths.
Maybe what would make sense is to re-use tsrc as a framework so that we can experiment with different workflows.
The idea is to avoid copy/clone same repository between several projects
Is #66 a viable answer for you ? You'll only have to fetch the history of a repository once, while still being able to use repositories from several locations.
For instance, you'll need to find the manifest clone path from any repository. Right now we do that by looking for the .tsrc hidden repository somewhere in the parent directories.
In my use case, i will run tsrc from inside a project tree. So .tsrc will be find manifest and .tsrc in parent directory. If not found, it is an error as it is already an error. In simple words, from manifest, we can go to abspath (ie cd abspath && git status) but from abspath, we can not find associated manifest and it is a correct behavior.
tsrc must be run from inside project tree : true.
But project can refer to external sources outside.
tools used inside project can go to external sources directories and perform actions (we use commands such as make -C xxxx/src O=$(PWD)/output or tar -C xxxx/src .... or pushd xxxx/src >/dev/null && ls && popd >/dev/null)
#66 seems a interesting improvement. To be honest, i have never work with git worktree. At least we don't duplicate history but we still duplicate sources.
One question about git worktree (corresponding with this issue use-case) : What happen if .../somewhere/soft1 is a git repository, i create an associated worktree (using tsrc) in .../my_project/soft1_worktree. Developer (me) will work in .../my_project/soft1_worktree If i remove .../somewhere/soft1, .../my_project/soft1_worktree is still functional ? What happens if some local work in .../my_project/soft1_worktree is not commited ?
Developers are used to have their git local repository at the same place as the sources they are working on. Using manually git worktree for a quick fix on a temporary worktree is pretty interesting. Using git worktree in a tool managing repository is maybe dangerous as the user will not directly see the operation and could remove local repo thinking it is not used. For him, the worktree is used and all git specific data are in this directory as classically created by git clone.
Just realized something else. If you put an absolute path like /home/foo/projects/linux, how is it going to work on a user named bar? How will it work on macOS, where the home is in /Users/foo ? And how will it work on Windows ?
Looks like you can't have absolute paths without also replacing environment variables like $HOME, no ?