tag:blogger.com,1999:blog-27232680.post8578112314027749846..comments2024-03-20T06:54:32.435+01:00Comments on Plastic SCM blog: Which elements must be under the version control?F3RD3Fhttp://www.blogger.com/profile/11524626976811746062noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-27232680.post-1993725319138481282009-10-17T00:57:51.220+02:002009-10-17T00:57:51.220+02:00Excellent point!
Of course we DO include binaries...Excellent point!<br /><br />Of course we DO include binaries on source control too. The point we wanted to explain is that "generally speaking" you put the sources and get the binaries out of them...<br /><br />But of course your point is sound and clear!!!<br /><br /><br />Thanks for the comments.Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-44148507395210843442009-10-16T19:55:32.206+02:002009-10-16T19:55:32.206+02:00Hi,
This is a very great system you guys built! D...Hi,<br /><br />This is a very great system you guys built! Documentation and resources are very helpful too! I enjoy reading this. Great job!<br /><br />I have a note why sometimes you may need to keep compiled and tested binaries along with the source code. <br /><br />We are using Delphi. Delphi compiler has such a feature to produce a random junk in some areas of your binary file. I don't want to touch here why it happens, it's a different topic. Whenever you compile the same source code you end up with different binaries. This would be a minor issue if it was not related to stability of your final result. There are type of low-level bugs which may try to use those junk areas. In some cases it may be harmless, in others it may completely blow up entire process. It depends on what type of random junk you've got in there.<br /><br />In other words, it might be a need to keep binaries along with source code (for history), instead of relaying on compiling.<br /><br />With respect,<br /><br />AlekseyUnknownhttps://www.blogger.com/profile/05327144997453122981noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-85080198553723233022007-11-08T19:22:00.000+01:002007-11-08T19:22:00.000+01:00Hi Pablo. Many thanks for your answer. This all m...Hi Pablo. Many thanks for your answer. This all makes good sense. Our source control methodology is a work-in-progress, so it's good to pick up more tips along the way.<BR/><BR/>Keep up the great blogs<BR/><BR/>Best regards,<BR/><BR/>RodRodhttps://www.blogger.com/profile/17287586636856638153noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-58312947265231969972007-10-30T09:05:00.000+01:002007-10-30T09:05:00.000+01:00Hi Rod,Well, this is a pretty good question actual...Hi Rod,<BR/><BR/>Well, this is a pretty good question actually.<BR/><BR/>I'd put everything under source control, including installer packages, database scripts and the like.<BR/><BR/>For database scripts the scenario is pretty simple: they'll be handled as regular text files, so you'll even have merge capabilities available.<BR/><BR/>For binary-based assets things get a bit more complicated. I'll give you an example:<BR/><BR/>- We have two repositories (well, in fact our own source code is split into at least 5 reps, which wouldn't be a regular practice for such a project, but it is a good *eat your owns dog food technique* for us) one of them containing test code. The binaries generated for testing are actually copied into the "src" repos to test. Well, if two of us have to make a bug fix and generate a test case to check it is correct, we'll both generate the tests and replace the test binaries in our branches (streams).<BR/><BR/>- Later on the integrator will notice there's a problem with the binaries, because Plastic will ask him to choose between one library and the other. He'll take one of them, and later on recompile the test binaries and replace them...<BR/><BR/>The problem here is that merging binaries (executables) is not possible.<BR/><BR/>For installer packages it could be simpler when you're dealing with the installer configuration itself: most of the modern tools treat them as XML or some sort of text files. So merging would be possible. The resulting installers wouldn't normally be included inside the repository (ok, they could be stored in some sort of stating area to be used by third parties, but this is a whole story itself) so you won't be in trouble merging them.<BR/><BR/>So, in short: yes, use your fix-branches to modify not only source code but also installer package generation, database scripts, help documentation source, and so on.<BR/><BR/>If any of the assets shouldn't be modified in parallel (it can happen for some file formats), then Plastic will enable to do so using the selector. If this is the case just let me know and we talk about it further.<BR/><BR/><BR/>Thanks!<BR/><BR/>pabloPablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-8763331189189214692007-10-30T03:25:00.000+01:002007-10-30T03:25:00.000+01:00Hi there,Just wanted to say that you've got a grea...Hi there,<BR/><BR/>Just wanted to say that you've got a great series of blogs going here. I've been reading them from the beginning and they've always been entertaining, informative and regular. Keep up the good work!<BR/><BR/>I've a question for you. A while ago you posted a blog that explained that you create a new source control stream for every bugfix, or feature that you work on. My question is, do those streams also include all of the source control artifacts as well as the source code? For example, do those stream include things like Installer packages, database scripts, help documentation etc?, or are they just source code only?<BR/><BR/>If they don't, how are you managing these other things? For example, if a bug fix requires an alteration to an installation package (Installshield etc), how is this managed?<BR/><BR/>I am trying to put together a source control methodology and I am starting to lean toward putting everything into one stream and the whole thing gets created for each fix.<BR/><BR/>Many thanks,<BR/><BR/>RodAnonymousnoreply@blogger.com