I'm trying to create a branch spec that only pulls down specific folders from a repository, but preserves the directory structure.
For instance, in the repo the project looks like this:
project
->1.0
->Common
->ProjectSpecific
->Project1
.Project specific files
->Project2
.Project specific files
->2.0
.
.
.
->_env
.
.
.
->c
.
.
.
->setup
.
.
.
.general project files
What I'm trying to do is create a branch for each project that pulls down all folders, except in the 1.0/Project sub directory, it should only pull down the Project folder specific to that folder. I'm guessing this isn't possible purely with a branch spec (I've tried and always end up with everything in the same directory or other problems). I've tried creating a seperate codeline with a client view, mapping every directory under project, and beign sure to only map the Project specific folder, but it didn't work, and I'd really like to avoid having to create a new codeline for every project.
Is their a way to do this from a branch spec? Alternatively, is there a way to blacklist folders? Then I could simply map the whole project directory and just blacklist the projects I'm not interested in. Any help would be appreciated. If I'm not being clear, let me know and I'll add more detail.
Thanks
You can blacklist folders by adding a minus to the beginning of the line for the mapping in the branch spec.
See the Perforce documentation on Views for the gory details.
Right, you can use branch specs to include/exclude what you want. Streams provide an even simpler way to specify the files you want.
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.
I'm trying to use dupFinder to scan for duplications in a .NET codebase. I have certain files and folders that I want to exclude from the scan but I'm struggling to get it working.
The command I'm running is:
dupfinder.exe --show-text --output="dupReport.xml" --exclude="Some.Folder.*;*Resource.designer.cs" MyCode.sln
So what I'm trying to do is:
Scan the MyCode.sln solution.
Ignore all folders matching the pattern Some.Folder.* e.g. Some.Folder.Code and Some.Folder.Tests (these folders are in the root of the repository alongside the solution file).
Ignore all files matching the pattern *Resource.designer.cs in any folder i.e. MyCode.Resource.designer.cs.
I'm sure I'm just doing something wrong but the dupFinder documentation doesn't show an example of using the exclude option.
I have eventually managed to get this working, the conclusion I've drawn is that you can't exclude folders only files.
I think because my original exclude pattern was trying to ignore folders the whole thing wasn't working.
I know this is an old question but I also searched for this.
To exclude complete folders you should use double *
e.g.
--exclude="**\Tests\**;**\Resource.designer.cs"
excludes all Files in all Tests folders and Resource.designer.cs in whatever folder.
Edit:
Tested and still working on JetBrains.ReSharper.CommandLineTools.2020.3.4. Which was the current version when I wrote the answer.
Current version seems to have a bug again and not excluding at all.
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.
Is there a possibility to add directory (with sub directories) to SupportFiles section in installshield. I have dynamically created content (list of files changes constantly) that I use to support my installation.
Is there any other method to add dynamically whole directory to installation package. I need files from this directory only during installation process. At the end of the installation I want IS to remove these files automatically ?
The ISSetupFile table ( which drives the Support Files pattern ) only supports extracting files to a single directory. There is no way in the UI to tell it to be dynamic although you could have a build automation step that reflects the contents of a directory and wires it up to the table using the automation interface. This still couldn't do sub directories though.
What you probably want to do is creating a self-extracting zip of the files you need as part of your build and add that EXE to Support Files. Then write custom actions that call the EXE to extract the payload to Support Files and another CA to clean it up. Look for the custom action ISSetupFilesExtract and ISSetupFilesCleanup to figure out the best way to do this.
Although I'm late to the party: #BuvinJ mentioned in a comment that you can add directories to "Advanced Files" under "Disk1." In this case, they do appear in the temporary directory (support directory), eg. SUPPORTDIR\Disk1
SUPPORTDIR is a temporary location where the installer dumps files, and cleans them up afterward. An example is C:\Users\<your user name>\AppData\Local\Temp\2\{F6B9B2D6-2A5A-4146-9297-E80A199CB0CB}.
This could be a quicker/cheaper/faster solution to writing custom actions and/or packaging up files by hand in, say, a self-extracting zip file.
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.