I use Tortoise SVN and I have one repository called "First". My SVN Location is C:\SVN.
Now, I created a new project in repository "Two".
The current structure is
C:\SVN
-> First
-> Second
I have few classes in First that I want to use in Second. Earlier, I just used to copy the files and modify it in second, but now since I am using SVN, I think it makes sense having just one copy of the class files and reusing them.
How can i check out the classes in First to be used in Second? And when I modify the classes, how can i update First??
Thanks.
You can reference a sub folder (or the entire repository) of repo First in repo Second using svn:externals.
This way when Second is checked out, it will also check out the files referenced from repo First.
Then, when you are using repo Second, and you modify the referenced class from First, you can commit them back. You will have to do this explicitly at the folder level used in the svn:externals reference, though. If you commit at the top-level of Second, it will not automatically commit changes to the sub-folder referencing First.
Either add projects that exist in First in Second, or add the files from First into your project/solution in Second. Note that this will assume a directory structure. For example: if First needs class A from Second, in the first solution, provide a link to file "..\First\A.class". Then it will be compiled into your Second project, but will really reference the file in the other repository, so updates to it will be made in the first repository.
Related
Is there a way to modify folder structure (path) for pushed commits in Gitlab?
For example, my old path is homework, now I want to add a parent folder before that, i.e. superfolder/homework? Tks and welcome for any help
If you want to do so while keeping the history of homework, you need to install the Python-based tool newren/git-filter-repo.
That tool has a renaming based on paths option
In your case:
git filter-repo --path-rename homework:superfolder/homework
Note that it changes the history of the repository, which will have to be forced pushed (git push --force): not a big deal if you are the only one working on it.
Gitlab Markdown has support for references to files in the repository structure, like:
[README](doc/README)
or
[README](doc/README#L13)
But are there ways to reference files and lines in these files, but from a given commit, at least in the Wiki ?
Maybe something like:
[README](1ab3fa71:doc/README#L13)
or using the file hash id like:
[README](9a27b101#L13)
To use relative links from wiki to the repository (or wise versa) is not supported officially according to Gitlab's documentation (cited from v11.5, still valid for v15.3):
Note: Relative links do not allow referencing project files in a wiki page or wiki page in a project file. The reason for this is that, in GitLab, wiki is always a separate Git repository. For example, I'm a reference-style link will point the link to wikis/style when the link is inside of a wiki markdown file.
There is, however, a syntax which seems to work currently:
[[README|/../blob/1ab3fa71/doc/README#L13]]
But be aware: all text of the same paragraph will just be lost!
I work around that by phrasing like this, which renders like expected for Gitlab CE v11.3.0 at least:
Here you see xyz:
* [[README|/../blob/1ab3fa71/doc/README#L13]]
The root-anchored link (/../blob/<version>/<path-to-file>) ensures that it works from every Wiki page independently from their nesting depth.
For sure this syntax also works for branch names or any other relative link like /../tree/1ab3fa71/doc for example.
Maybe long after the battle, but I found a workaround : Simply make a link to a page where the README.md is. And that's it !
To get the link simply go to a page which displays the document, copy the URL, make a link to that address, append #L with the line number.
Exemple :
[Readme Pelargos](http://192.168.80.250:10080/project-root/android/Pelargos/blob/develop/README.md#L47)
One way I've found that, for the most part, works is to mouseover the line of code that you want to reference in the relevant file. While doing that, click the link icon that appears in the lefthand-side gutter to copy the line reference. With it copied, you then use a slightly revised version of the path in the copied URI.
Here is an example of a link copied using the gutter icon:
https://gitlab.com/settermjd/mezzio-sms-sender-api/-/blob/main/src/App/src/Handler/SMSReplyHandler.php#L23
This is the revised path that I used in a commit. Note the parent directory reference prior to main/:
/../main/src/App/src/Handler/SMSReplyHandler.php#L23
I realize that the file reference in the gitlab wiki, references files from the wiki repository itself and not from the project repository (source code repository).
However, when you make a reference to a hash, it knows if the hash refers to a commit or a file, so you can make references to a specific file from the project repository.
I have the following TFS configuration
Root\
Proj1\
App1\
...
App2\
...
Proj2\
Lib1\
...
Lib2\
...
App1 and App2 both have project references to Lib1 and Lib2.
App1 does not reference App2, and Lib1 does not reference Lib2.
Now, I want to make changes to Lib1... but I want to branch it because the changes are drastic. These changes shouldn't require changes in either app1 or app2.
I created a branch Lib1Branch1 in TFS... but App1 and App2 both still reference Lib1 rather than lib1branch1... I don't want to manually re-reference the branch in each App (In actuality I have much more than just two).
When I used SVN, if I branched a project, and switched to that project, the local folders kept their original names and only the contents changed... thus building with one branch of the lib vs. building with the other only required that I switch branches and do a get-all... how do I get similar behavior using TFS?
I think you have a misunderstanding.
A Project is a self contained piece which is part of a larger thing called a solution. For example, a single class library is one project. It may reference other projects.
There are several ways to do branching. Minor branches might just require branching a particular project within the solution (such as Lib1) while major changes might require branching the entire solution.
It sounds like what you need to do is change your TFS structure slightly, then branch the entire thing. For example, the folder structure should probably be similar to the following:
Root
\1.0
\Web Apps
\App1
\App2
\Libraries
\Lib1
\Lib2
Then, when you branch, you take the entire 1.0 branch. That way all references are preserved between the two branches.
At work we are using Perforce and I wonder if it's possible to do submodules with it with versioning.
For example I have library A used by projects B and C.
I want to make it so that when I get revision of B I also get A in subfolder:
B
---=> A(v1)
Same goes for project C, but it would need newer version of library.
C
---=> A(v1.2)
I know this kind of thing is possible with Git, but could not find anything on it for Perforce.
Thanks,
Leonty
Perforce really handles this sort of thing with views and paths. These let you assemble the right set of files to put into a workspace (or branch or label). Since a Perforce repository can contain all of the components or modules for all your products, you just select which ones you want in a working data set. You don't need the submodule (or SVN external) concept to pull in data from another repository.
You can use template workspaces to make sure that developers get the right set of files to work on. You can be a little more rigorous and write some custom tools (possibly in the Perforce broker) to provide some structure.
The closest equivalent to using submodules is found in Perforce streams, where the paths define what goes into a stream. Stream paths are inherited by child streams. This isn't a direct equivalent though.
I have a repository that has the following directories:
branches
tags
trunk
The trunk directory contains the main line of development. I have created a post-commit hook script for the repository that updates a working copy (of trunk) when a user commits back to repository.
It looks something like this:
/usr/bin/svn update /path/to/a/working/copy
I've just created a branch of the code as I'm about to start some major changes but noticed that when I commit my changes to branch it calls the post-commit hook and updates the working copy (copy of trunk).
Is there a way I can modify either my post-commit hook script or a setting that I can make that would only update the working copy if the commit was made to the trunk directory and not any other directory?
As you can see in this documentation, parameters are passed to the post-commit script.
The repository passes two arguments to this program: the path to the repository, and the new revision number that was created.
The post-commit hook could be any program of any type : a bash script, a C program, a python script...What happens is that the shell launches this program, with the two parameters.
You can find a list of interesting scripts here. A good beginning would be this python script, which uses the python svn libs.
Please note that the path provided is not the same as the path to the file that you are checking in (see Paul's answer). But using this information with the revnum should help you to get the list of the changes, from which you can determine if operations have been done on trunk or not.
In addition to the answer from Bishiboosh, it is worth noting that the hooks can be any program. That is, if you wanted to, you could write the program in C. The parameters that are passed are described in the doc.
For a good repository of scripts to get inspiration from, have a look at the subversion tools page. In general, if you want to do some conditional processing based on the contents of the transaction, and you do, since you only want to process if the files are in trunk, then it will be easiest to use Python, since that comes with a bunch of tools to examine the transactions. This script is a good place to start looking for inspiration.
Note, that the path to the parameter, is not the same as the path to the file that you are checking in. You could have multiple files in the checkin after all… What you are passed is the location of the repository, and the revision of the change. Using these two pieces of information you can get the information about the change from the repository, and use that information to decide whether to perform an action or not in the post-commit hook.
Here is another example (in Perl) That explicitly checks the path of the files in the checkin. This is a much more complicated script, but most likely the salient parts can be ripped out and re-used.