Understanding How to Own a Subversion Repository

I used to use file server + update person, then CVS for the next generation, and now Subversion.
Before Subversion, it was almost like a place to put programs and how to make them, but now I can't keep up with the development site's movements with such management. Therefore,

Basically, there is a per-customer repository commissioned
Repositories include /trunk, /branches, and /tags.

The general usage rules are as follows.

Cut off branches for each customer request/development component, where development is concentrated. Once the development is complete and you enter the maintenance phase, merge into /trunk.
However, if the current program has a bug report, cut the branch from /trunk, take action there, and merge it into /trunk when the fix is complete.
Also, it is difficult to separate program development units like version NN, but the order/delivery will be completed on a yearly basis, so I will move it to /tags from /trunk. (Cut off branch)

What I want to ask is how to use different versions. As this is a customer-specific project, there is only one repository allocation, but I also have to manage the following.

Documents (this is not a big deal, so it doesn't matter much)
Test data passed by customers (although development members have to share it with each other, sometimes it's huge)
Font, etc. (Recently, some customers use Noto fonts, so I put them in Subversion to create an environment at once. It's big.)
Utility-like programs that are not directly released to customers, but that are developed/used to convert and validate data

Let's say you put these things in /trunk, depending on when you put these files in and when you cut the development/failure response branch from /trunk, but creating/deleting files often causes a bit of overhead.

How is it best practice to build a repository if you are not familiar with version control as described above?

11. will have different folder configurations for /trunk, /branches, /tags and /docs, /test-data, and /resources.

I look forward to hearing from you.

That's it

svn

2022-09-30 21:58

1 Answers

あくまで It's just the way I think of the arrangement, not the best solution.Please read it afterwards.

As mentioned in the same comment, I think it is better to decide whether to include the data in the svn repository based on whether it is necessary for version control.

Include documents in the repository as they vary from version to version.However, it is not created in parallel with the existing /trunk/branches/tags and is stored in the same column as the code.However, as the question states, the waiting time at checkout increases (I've actually managed it like that...) and if the amount of documentation is huge depending on the size of the system, consider having a repository dedicated to documentation depends on the size of your system.
The test data passed by the customer is considered to be immutable data for use only in that version or later.Therefore, it is not included in the repository.The problem is that the data size is large, so I think there is no problem if you store it in a separate storage and include a memo with the storage location in the relevant version.
Resource files, such as font files, are part of the system and may change depending on the version upgrade, so would you like to put them in the repository?If it is essentially immutable, it might be a good idea to store it in a separate storage and leave it in the repository with a destination note or write a batch file that you copy from the storage.However, if it's just a font, I think it's possible to consider turning it into a CDN (it can't be helped if you can't connect to the Internet).
If the development assistance program or utility is specifically for the customer's product, I think it is safe to manage the version as well as the source code.I think it's appropriate to use a separate repository to manage the common utilities for multiple projects.

One more thing about documentation.The repository I used to manage at my previous office was for the following:

/Department name
　/A-system-src
　　/trunk
　　/branches
　　/tags
　/A-system-doc
　　/trunk
　　/branches
　　/tags
　/B-system-src
　　/trunk
　　/branches
　　/tags
　/B-system-doc
　　/trunk
　　/branches
　　/tags

The source code and documentation are in separate subdirectories, so a large amount of document side data does not affect the source side.However, in this configuration, the version control function that came with IDE is almost unavailable, so there was some inconvenience.
I don't manage documents by IDE, so I think it's a good idea to create a /docs directory and make it a different subdirectory from the source code side.However, I think it would be better to decide whether to manage the version or not (it will end up being a separate management that does not work with the source side).

2022-09-30 21:58

If you have any answers or tips

Popular Tags

python x 4647

android x 1593

java x 1494

javascript x 1427

c x 927

c++ x 878

ruby-on-rails x 696

php x 692

python3 x 685

html x 656