Cool! I was afraid this easily become into one of those "soliloquy" threads, so thank you first of all
Genete wrote:welcome to the complex world of coding!
Yeah, it has taken to me more than a year since your (wise) advice about it, but finally (and fortunately) I've been able to decide to face up the issue and, although in a very primary way for sure, I think I'm already tasting some of the sweet flavors of this new level of "control"
Genete wrote:I deduce that there are some files that are common between different projects, right? What I don't understand is why that represent a problem?
Although you have different projects (or lets call them features) at the end, all they will be merged together, right? I mean, those features will work all together and won't produce different set of folder/files, Am I correct?
Well, I never would have said either that so simple (and I thought common) situations, in which dependent or shared resources between projects (or rather, different AS tools) comes into play, could represent a problem for Version Control but, although it seems "possible" by means of the aforementioned solutions (
Submodules/
Subrepositories), it can complicate and limit workflows in a manner that I don't think I can deal with, for now at least... But, fortunately, involved elements are in my case very few, as said, basically the typical and unique "rl_utilities.lua" file which, being by its own nature intended/conceived to interact with ANY other independent project/tool's code, will be "susceptible" to be modified at ANY time and from WHICHEVER project/tool (and, therefore, different repositories) be in development process, and well, I'm simply not sure yet how this is managed by CVSs and if it could cause conflicts or history problems in the future (but I admit there are still a lot of concepts about CV's internal functioning that I totally ignore). OTOH, for your words I deduce it couldn't be a problem at all as long as I take special care about updates (which, although maybe kind of
uncomfortable, is logic and convenient cause, after all and as you suggest, the idea behind this kind of shared resources is they must be compatible and "up-to-date" to every involved project (IOW, I want the last version of "rl_utiulities.lua" works fine with everything else: older AND new). So, assuming Git/Mercurial doesn't provide a solution equivalent to the named "
svn:externals" (which, if I understood it well, should manage and take care about that kind of updates when needed), I think I'll have this main choices in order of preference...
- Work with ONLY ONE "rl_utilities.lua" kind of shared files and SEPARATELY, that is; in a totally different/independent (and, therefore, external) repository, be making changes as needed and (and here is what I mainly wanted to avoid) be manually Copy/Pasting the "rl_utilities.lua" file into all the other involved repositories as needed, then, update them all. That way, if I'm not missing something (that I doubt), every repository will save its own snap of the file in history and I should be able to go dealing with "rl_utilities.lua" development and bug fixings by means of its own repository without major conflicts or history problems on dependent repos. Hmmm, I'm not totally sure but this sceario could be near to the solution you propose, isn't? Anyway, at least it seems to have some sense in my head... As I said, the main handicaps I see on this are (assuming it doesn't break any basic VCS rule) the manual managing and copy/pasting, although OTOH, this method will allow me apply the same "symlink" solution I'm using for normal projects/tools in order to solve the structure folders problems I mentioned, as I'll explain later.
- [DISMISSED]I had in mind an alternative way consisting on go working with SEVERAL and different "rl_utilities.lua" copies inside each involved project/tool/repository, but I see now why this wouldn't be reliable at all, not only because it'd easily become a mess but it would complicate the "symlink" solution I was talking about, I mean, I should be updating their "symlink" in the AS "utilities" folder to target the WIP "rl_utilities.lua" copy each time I go making changes on them from the different projects/repositories, in order to can make ongoing AS tests.[/DISMISSED]
Well, I have to learn some more things about workflows in general and branching in particular, in order to can really say and feel comfortable with all the concepts, but I think I get the basics behind the workflow you propose and, precisely, the possibility to work in that way what made me discard the Subversion option in favor to a Distributed Control Version System like Git or Mercurial, concretely the last one, with which I star to feel happy as far as I've tested (not as much as I'd like

). But, if I understand it well, you are proposing something like a "super-project", or rather: "SUPER-REPOSITORY", which should contain ANY other project as long as any shared file between them exists, isn't? (otherwise, files interaction between totally independent repositories wouldn't be possible in Git or Mercurial as far as I know). Well, certainly that possibility have passed through my mind at some point but the lack of sureness around all this, made me start experimenting with independent "per project/tool" repositories , but this is something about I definitely want to delve and requires much more thinking for my part, as I like to start on the right foot if possible, cause I'm always afraid about if once initiated the workflow of choice, there will be a point of "no return" for deep changes in the way it was conceived.
About the VCS of choice, it was not an easy task... but I finally decided to start working with Mercurial as long as it seemed to me a little more "attainable" in concepts and I perceived the "TortoiseHg" option as a little more consolidated than the "SourceTree" one (which I just discovered the other day by a very opportune
genbetadev article, BTW), but luckily (and under my little understanding) the Mercurial and Git main concepts and workflows can be very similar so I hope such decision doesn't affect too much in the way we could understand each other on this matters (?).
Well, I wouldn't stop.... but I think I'm still running my mouth too much and maybe I should stop here and leave other possible points to be discussed in the way you suggest

. Again, thank you very much for be there trying to make this kind of "out of this world" things seem a little more bearable for dummies!
EDIT: Oh, about the "Symlinks" part... well, as I implied, I'm simply making use of relative Soft (there seems no need to go Hard) Symbolic Links in order to can separate working directories (repositories) from the
imposed AS's folder structure in which the lua files must be placed in order to can make the typical (and so recurrent) "Alt Gr+F5" instant tests. And it seems to work like a charm and, as far as I can say, with no drawbacks! Cause this way I'm not really messing Git or Mercurial (which doesn't seem to support Symlinks very well, at least in the
expected way) with them, but simply "cheating" AS about the real placement of the files. This can seem a silly/basic thing, but it solved at a stroke one of my main concerns and doubts around the entire issue.
...