I’m starting to use version control on several projects (with GitHub). I converted the project into a version control project. It created a bunch of folders for Classes, Modules, Windows, etc… as to be expected. But I have another project in the same folder that I want to convert into a version control project. Will it create its own version of each of these folders or will it be smart enough to share the same folders? And will this cause any problems? What if I have two classes share the same name across both projects. Will it be able to differentiate the two? etc…
(The reason these projects are in the same folder is that they share a lot of the same resources (images, audio, and some external classes) so putting them in different folders causes all sorts of problems.)
Text Projects (VCP) should be contained in their own folders. If you are sharing items, share them using External Items in a separate folder. Otherwise, I’d say you are just asking for something to get unintentionally overwritten.
yeah don’t put two text projects in the same directory - you’re asking to clobber yourself or files that have similar names and all kinds of bad things will ensue (none of which are bugs)
There are so many shared references between the two projects it is nice to keep them together. And it is a nightmare when I try to separate them. If I do and I launch Xojo I get 100+ prompts to locate specific files – It’s not really practical to resolve this way. I often have sets of these located in a single folder though. It would be nice if Xojo was smart enough to prompt me to find that folder instead of trying to relocate the dozen or so files located in that folder.
Text projects use names to locate things & if you have two items with the same name in two different projects at the same location that ARE supposed to be distinct you’ll constantly be clobbering one when you edit the other project
We COULD use some other ID but then using version control would be hell since you would have no idea what file related to what items in your project
I’m just giving advice
You can do what you want but when it becomes hell to manage or you constantly clobber one project or the other remember we said “Don’t do this”
[quote=67896:@Norman Palardy]I’m just giving advice
You can do what you want but when it becomes hell to manage or you constantly clobber one project or the other remember we said “Don’t do this”[/quote]
Sorry but, what we really need would be a Do this , instead
The way I handle this in SVN is to make a separate repository for the shared items and then check out an External copy into each project folder. The advantage to doing this is that they each have their own individual revision of the externals, so if something changes which breaks one of the projects, it doesn’t necessarily bring production to a halt. You can just revert to an earlier version of a particular item. The trick is that the IDE currently doesn’t allow you to import a raw VCP file, so to add something, you need to create an identically named item in your project, save, close the project, delete or revert the item on disk, and then open the project again, where the IDE will ask for the location of the missing item and you need to go find it.
I believe this is not a serious approach to the problem.
First, this is an hack, similar the one described above and for which Norman says it can be dangerous. Also Im not sure this kind of "swapping items under the back of Xojo is officially supported. And if its supported, then it’s really a bad way of solving the problem.
Secondly, using external items, really make sense for having a single repository for included code (classes, whatever) so everyone always get the latest version. I see no use of having ten different versions of the same class, one for every developer. The more code you have, the more code you have to maintain.
And about code integrity protection, this should be achieved with unit tests, not making copies of the source code.
that depends on what version control system you use so there’s no generic answer
with svn sub projects for common code works well
with vault you can have it handle the shared items in a separate repository and it does the copy & merging for you when you check out check in
not sure about git but I suspect submodules is a way to do something similar
or use external items as is but that does mean you use binary or xml
or each project has a copy that you’ve placed there & that does NOT auto update (I think bob keeney uses this approach so HE controls very explicitly when individual client projects get updated and I used the same approach when I had multiple clients with projects in different releases of xojo/real studio)
and I’m sure there are other options that I’ve missed
BUT while the textual format is useful with version control systems it’s handling of external items has always been, from its inception, less than ideal when you want to have multiple projects sharing one bit of code
This is not new
Quite literally this format was not designed to be used the way you want to use it
[quote=68161:@Massimo Valle]
First, this is an hack, similar the one described above and for which Norman says it can be dangerous. [/quote]
Not really
This is two projects in two different locations where YOU deliberately overwrite items so you can share “common” code
Thats different than doing it by accident as might happens in Brocks case
You can do a fair bit manually (i.e. hit save move the common code to a different location on disk then open your project & relocate all the moved items)
BUT - if you move them in your project then they WILL get written in whatever new location the IDE thinks they should have within the overall project hierarchy on disk
[quote=68185:@Norman Palardy]
with svn sub projects for common code works well
with vault you can have it handle the shared items in a separate repository and it does the copy & merging for you when you check out check in[/quote]
Some clarifications about the above configuration:
shared items are externals or internal for Xojo?
what do you mean with copy & merging for you?
In the end I’m trying to find a way to share items among projects, without the limitations of Xojo external items (xml only, no namespaces).
[quote=68234:@Massimo Valle]Some clarifications about the above configuration:
shared items are externals or internal for Xojo?
what do you mean with copy & merging for you?
[/quote]
In the case of using VAULT they can be internal and the tool manages the common items
Vault basically knows that you have set it up to have “aliases” so you project is blissfully unaware that this has even happened
[quote=68234:@Massimo Valle]
In the end I’m trying to find a way to share items among projects, without the limitations of Xojo external items (xml only, no namespaces).[/quote]
Using VCP you will need assistance from whatever external tools you use and how you do it will depend on what tool you’re using
But there’s nothing in Xojo that will assist you - its text format is just not designed to do what you want
I know I know - change that - easy to write & damned hard to do
Hence why 17863 hasn’t moved much beyond the “information gathering stages”
This comes down to
you - I want to use this hammer as a screwdriver
me - its really not designed to be used that way
you - Yes but I really want to
me - I suppose you can find a way to make it possible but its really not designed that way
you - Yes but I really want to
me - I suppose you can but if it breaks its not the toolmakers fault
you - Yes but I really want to
So OK there may be a way but it will definitely be a “workaround” (or hack if you want to refer to it that way)
It sucks, I too wish it weren’t this way, but it is
Btw, I understand the situation, and I appreciate your efforts to find alternative ways ,really, but the fact is I need a hammer AND a screwdriver to build.
And, not to pour more oil on the fire, I believe the Xojo text format has some design flaws.
I found very easy to corrupt a class or the whole project during a merge, due to the weakness of the format.
This is not about introducing some errors in source code that it won’t compile anymore, is just that if you misplace some tags or sometimes even a space, you can’t open the project anymore or at best your class is gone. And Xojo says nothing, simply ignore it.
For this purpose, I think the text format should be redesigned to strongly separate source code from other informations, so to limit as much as possible the chance of corrupting it.
(what about 17863 ? I can’t find a such feedback case. Is it private or what?)
[quote=68284:@Massimo Valle]Norman, thanks for the explanations, but what’s VAULT?
This? SourceGear | Vault
[/quote]
yes that one
[quote=68284:@Massimo Valle]Btw, I understand the situation, and I appreciate your efforts to find alternative ways ,really, but the fact is I need a hammer AND a screwdriver to build.
[/quote]
I’m not saying you don’t - just thats not what is there
you - I want to use a hammer and screwdriver
me - yes the toolkit we have for you today has a hammer
you - Yes but I really want to use a hammer and screwdriver
me - the toolkit we have for you today only has a hammer
you - Yes but I really want to use a hammer and screwdriver
seem familiar ?
Am I to understand that you edited it by hand, misplaced things & then its our fault you edited it and got things wrong ?
Or are you saying something else ?
We use SVN all the time & never have issues with merges wrecking our projects (the IDE for one) BUT that may have something to do with how conflicts are resolved
Now knowing whats transpired its hard to know a) why b) what to recommend
For us we NEVER use automatic resolution of conflicts in our client tools (Cornerstone, SyncroSVN or Tortoise because it just doesn’t do what you think it should - they really have to be revolved by hand then marked resolved)
If you want a format that is harder to corrupt maybe use the binary format ?
[quote=68284:@Massimo Valle]
(what about 17863 ? I can’t find a such feedback case. Is it private or what?)[/quote]
I see, but It doesn’t work in that way.
Try to sell a toolbox to a carpenter without a screwdriver then, when he starts to complain, tell him the above.
[quote=68330:@Massimo Valle]I see, but It doesn’t work in that way.
Try to sell a toolbox to a carpenter without a screwdriver then, when he starts to complain, tell him the above.[/quote]
I’m not trying to sell you anything new
I’m addressing the “I bought this but it doesn’t do everything I want” sentiment you’ve expressed
you - I bought the toolkit but I really wanted to use a hammer and screwdriver
me - yes the toolkit we sold you had a hammer
you - Yes but I really wanted a hammer and screwdriver
me - the toolkit only had a hammer
you - Yes but I really wanted a hammer and screwdriver - can you please make one & give me a screwdriver ?
me - the toolkit has a hammer and we’ll need a new factory to make the screwdrivers
you - Yes but I really wanted a hammer and screwdriver - please give me a screwdriver for the toolkit I already bought
I understand why you want that - I really do
And we do have a report with lots of notes about what we need to fix in the text format
But we haven’t started building that yet - its a fairly big undertaking to create a new format & not limit it the way VCP currently is
I’m sure you can find a way to do what it is you want - its just not built in. Sorry.
Thats all I’ve said
