Click here to Skip to main content
15,867,704 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hi all,

I'm interested in learning what is considered best practise within a repository that contains a project that requires several independent developer licence files for building and publishing the solution. The licence files (*.licx) are needed for the components/tools used within the project (I don't mean for the product itself).

We have a couple of developers that all have their own licence files. If these licences need to be in included in the solution in order to build it how should they be handled during update/commits to the repository?

I am using TortoiseSVN.

Thanks,
Posted
Comments
ZurdoDev 16-Nov-15 10:09am    
You just need to make sure not to include them. You should already be not including the .SUO and .user files for example. There are others you shouldn't check-in either that are specific to users. Just handle the licenses the same way.

1 solution

I would do all the development on some special development versions not using license files at all. If assembly signing is involved, you could also use delayed signing (https://msdn.microsoft.com/en-us/library/t07a3dye%28v=vs.110%29.aspx).

In the Subversion code database, you should store only the source files. Many developers poorly understand which files in their projects are source files and which are not — this is a nasty problem which should be solved from the very beginning and not allowed to happen. In some cases, some file which is external to development and is not technically a source file, can be added. Such files are also should be stored somehow, because there are no any other, "more original" source for them. As they are not part of the development process, and supposedly (almost) never change and are not subject of creating development versions, I would suggest to store them, including license files, separately. With Subversion, I would suggest using the mechanism of external files: http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-externals.html[^].

The Microsoft article referenced first, about delaying of signing, touches a very delicate aspect which may be related to your work: the technology where the development team is not fully trusted, so part of the programming asserts is kept in secret from all or some team members; the article describes one of the technologies limiting developers' access in this way. You have to decide on that by yourself, but my own opinion is: trust the developers in this respect, as not trusting them can create moral hazard. Revision control and other technical tools should only protect against accidental mistakes and, say, incompetent steps, not from stealing property; developers should be loyal to their organization based on moral principles and some incentives, not by keeping people in technical handcuffs.

—SA
 
Share this answer
 
v2
Comments
GetReQ 16-Nov-15 11:07am    
That's very useful, appreciate the material you've provided.
Sergey Alexandrovich Kryukov 16-Nov-15 11:17am    
You are very welcome.
Good luck, call again.
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900