Re: [Monotone-devel] [Monotone-users] CAD versioning
Hendrik Boom hend...@topoi.pooq.com writes: On Thu, Dec 12, 2013 at 11:44:51AM -0600, Stephen Leake wrote: Roberto Bartola robertobart...@gmail.com writes: I'm looking for a versionig software which could be used in (M)CAD projects. I such projects we can find many parts assembled in assemblies and sub/assemblies. I'd like to understand if is it possible to checkin/checkout and put in a lock way the assemblies with its component. It is certainly possible to commit the files to monotone; it can handle any files. Monotone can certainly store any files; but can it merge changes to those files? If not, you can specify an external merge tools. Or use a front-end that supports other merge tools. If there isn't a merge tool for your file format, then that's a problem. The typical solution to not being able to merge files is to forbid parallel editing. The OP did mention locking, which is one technique to enforce a no parallel editing policy. monotone does _not_ support locking. locking requires a central repository, at least for the locks; monotone is specifically designed to _not_ require a central repository. Other CM systems, that are _not_ distributed, do support locking. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Monotone-users] CAD versioning
On Thu, Dec 12, 2013 at 7:30 PM, Hendrik Boom hend...@topoi.pooq.com wrote: Monotone can certainly store any files; but can it merge changes to those files? That depends on the file formats. Monotone does change merging on a line-by-line basis, Most word-processing file formats, for example, are terrible at enabling change merging bcause they don't represent newlines as new line characters, or because they use data compresssion. Straight ASCII text, with newlines, is much better, and possibly also Microsoft's rich text format (anyone know for sure about this one?) Really?? It would be a surprise to me that monotone's delta algorithm would only be efficient for text files, because I have been using monotone for many years on images and pdf files without problem regarding performance. I thought monotone uses xdelta, which is a binary delta algorithm that facilitates binary merges that can be easily applied to both text and non-text files. Am I right, or is monotone's delta algorithm only efficient for text files? Hugo -- hendrik To do it I need the version software could understand the CAD assemblies or (may be easier) the version software read in a txt file the way the components are assembled. If it's a txt file, the kind that's memant to be hand-edited, theres hope, What could get in the way is (1) if the entire txt file is, say, just one line. (2) if the entire file, as opposed to a few lines, changes wvery tine the CAD software makes a small change in the design. Most revision management systems have the same limitations. With monotone, it's possible to write custom merge rules. That may be complicated, depending on the file format. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel -- Hugo -- Hugo Cornelis Ph.D. GENESIS-3 -- lead architect http://www.genesis-sim.org/ Neurospaces Project Architect http://www.neurospaces.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Monotone-users] CAD versioning
Hi Hugo, Really?? It would be a surprise to me that monotone's delta algorithm would only be efficient for text files, because I have been using monotone for many years on images and pdf files without problem regarding performance. I thought monotone uses xdelta, which is a binary delta algorithm that facilitates binary merges that can be easily applied to both text and non-text files. Am I right, or is monotone's delta algorithm only efficient for text files? These are two different things. The fact that Monotone uses xdelta to efficiently store different versions of a file is an implementation detail, that is not (should not) be visible to the user (well, besides the fact that it saves disk storage). An automatic merging attempt on the other hand happens whenever there's a conflict for text files to be solved, and this merging attempt is line-based. Do not confuse them, they have nothing to do with each other. That said, if I remember correctly, one could hook in any other method for trying an automatic merge in case of a conflict on file contents, and that method could in theory also handle binary files (like zipped xml and the like). Regards, Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Monotone-users] CAD versioning
On Fri, Dec 13, 2013 at 06:16:01PM +0100, Thomas Moschny wrote: Hi Hugo, Really?? It would be a surprise to me that monotone's delta algorithm would only be efficient for text files, because I have been using monotone for many years on images and pdf files without problem regarding performance. I thought monotone uses xdelta, which is a binary delta algorithm that facilitates binary merges that can be easily applied to both text and non-text files. Am I right, or is monotone's delta algorithm only efficient for text files? These are two different things. The fact that Monotone uses xdelta to efficiently store different versions of a file is an implementation detail, that is not (should not) be visible to the user (well, besides the fact that it saves disk storage). An automatic merging attempt on the other hand happens whenever there's a conflict for text files to be solved, and this merging attempt is line-based. Do not confuse them, they have nothing to do with each other. That said, if I remember correctly, one could hook in any other method for trying an automatic merge in case of a conflict on file contents, and that method could in theory also handle binary files (like zipped xml and the like). Yes, exactly correct. Or at least, as I recall, too. There is a merge hook. And it could be user-coded to check on file type and subsequetly use the default merger, or any other, The big question is whether custom mergers have been written for particular file types. And whether they are easy to write. SOmetimes a back-and-forth conversion to a more mergable file type is the best remmedy. But let me discuss how bad this can get, There's trouble when merging files with large, heavily nested bracket structures. The default line-by-line mechanism can end up with mismatched brackets. Now this is no problem when processing, say, C code, because the textrual level is the level at which human beings intereat with the code in an editor, even though the compiler may barf. But with syntactic trees that the user never sees, such as the einormousy complicated word-processor data structures, when the word processor barfs, the user is clueless. The answer would seem to be to do write secialized merge tools that respect brackets. This can be done, say for an XML file that consists of a sequence of records (with one XML tag) containing fields (of specific other XML tags) which may contain some further structure. In other words, where every kind of entity has its own fixed place in the nesting hierarchy, and they are normally kept in the same order. But for bracketed tree structures where the nesting can vary, where you cah, say, wrap an extra while loop around a bunch of statements, there is no known efficient algorithm (at least the last time I looked; anybody know better?). The only solution as far as I can see to such situations is to change the way that data structures are written to a file. Perhaps give every possibly nested entity a unique ID, which you write out with the entity to give the merge program something to synchronise on. Links to those entities are then written by writing the unique ID. The application software must then rigorously maintain these unique IDs through processing, editing, and the like, The application can then write all these entities out in, say, alphabetial order. Such a file would likely be very mergable. Though you' may still have to worry about parts of the data structure accidentally becoming becoming disconnected from the rest. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
