Ayende @ Rahien

Jason commented on Source control is not a feature you can postpone to vNext

Mon, 21 Apr 2008 11:42:26 GMT

Can it be that we see a XML-file as a text file and therefore want it to behave like one, while it in fact is a XML-file and should be treated different? In XML content hasn't changed if you put two spaces between two attributes instead of one, but as a text file it has. This could be seen as more of a problem of the tool performing the diff than the lack of "strictliness" from the XML editor in use (see the "could" here ;) ). My point is that it's very easy to claim that a plain text file readable to us humans should be processed as a plain text file, period. But maybe we rather should use tools to tell us if the content is really changed? BTW: I alreday see the comments come flying :)

Joseph Cooney commented on Source control is not a feature you can postpone to vNext

Mon, 21 Apr 2008 09:25:04 GMT

Would running an xml canonicalization transform over the xml file prior to check-in be a way to work around this issue? Naturally it will depend on the nature of the change (if it is element/attribute re-ordering then canonicalization will work). Either way it's unfortunate to be having to think about work arounds like this for something that is not out of the door yet.

naraga commented on Source control is not a feature you can postpone to vNext

Sun, 20 Apr 2008 10:41:51 GMT

C# Programmer, in what way is YAML more mergable than XML? if it's used for object graph serialization it really doesnt matter whether you enclose string in quoation marks or not. INI is useless for anything more then simple app configuration. it cannot be used for complex data structures. Joshua McKinney, i aggre. XML is more about data than about formatting. i really like your idea about employing additional formating to support current text based diff-tools for xml data. xslt is nice way to achieve that. just take an example of XML Schema. in XML file with schema content formatting is even less important. ordering of type elements is ignored by xml validator but very important for text-diff. so what if we sort all types in a file by alphabetical order?

C# Programmer commented on Source control is not a feature you can postpone to vNext

Sun, 20 Apr 2008 07:15:14 GMT

I can't agree that XML helped a lot because the only remaining format is binary. Ruby on Rails have perfect YML format, which is realy simple and mergable Even old [ini] format like [section] property=value ... is more friendly source control

Joshua McKinney commented on Source control is not a feature you can postpone to vNext

Sun, 20 Apr 2008 03:43:20 GMT

*find infinite ... some *form of transform...

Joshua McKinney commented on Source control is not a feature you can postpone to vNext

Sun, 20 Apr 2008 03:39:55 GMT

Another way again of looking at this is that the xml really stores two parts of relevant information. Data in the form of elements, attribs etc, and presentation in the form of whitespace ordering of elements, attributes etc. It is the presentation that is by xml's very definition open to interpretation. Given a particular schema and a particular set of data it is possible to fins infinite ways to present that data in xml. Source control could take advantage of this to store a normative version of the data (e.g. all non relevant whitespace stripped, attribs ordered by name alphabetically, elements similarly ordered when appropriate. Attached to this would be some for of transform (xslt perhaps?) which would get us to the presentation that was last saved.by the designer. This would be good for diffs between versions, and could be extensible enough to even solve code style arguments (K&R vs allman)

naraga commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 20:16:20 GMT

in a way XML helped a lot (even though version control tools cannot catch ) because the only remaining "comfortable" options for most of vendors would be custom binary formats.

Stuki Moi commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 19:45:44 GMT

A fundamental problem is that the way these designers measure size of change is largely unrelated to the way a text-, or even raw xml-, based tool would measure it. If I save a ‘design’, reload it, make a small change, and save it again, in the ‘mind’ of the designer these files are very similar, even if they to a stream based differ look very different. Could shipping each of these tools with an attendant context aware differ, and rewrite the source control tools to use a pluggable such for each designer's chosen xml format make some sense? I haven’t fully thought through this, but it would seem this might be easier than forcing every designer to serialize in a way pleasing to existing source control systems. And I really, really don’t want to have to give up the use of designers. They are way too beneficial for that.

С# Programmer commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 17:51:01 GMT

Ayende - do you have any ideas with XML files merging problem? get all XML files generated from plain text by NAnt, and keep only that plain text in SVN instead of XML? Or you can write a megasuper 2-way processor XML-> plain text of xml - > merge plain texts from "our" and "their" version -> convers merges back to XML? How do you work with .csproj and .sln files, which are xml, during merging? And thank you for that post, I'll never use XAML due for XML merging reason

Ayende Rahien commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 15:54:26 GMT

Frans, I am fine with XML files and merging them. And I am not saying that you'll never have merge conflicts. The issue is what type of merge conflicts. If changing a single property results in 70% of the file being changed, that is not mergable. If changing a single property results in a single line being changed, that is mergable.

knocte commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 13:37:57 GMT

It happens the same with VisualStudio .sln files :( This people seem to be working with VSSourceSafe+exclusive checkouts, damn...

Joshua McKinney commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 11:18:02 GMT

The easy way to look at this problem is that there is an impedance mismatch between the visual designer, the xml representation of the visual design, and text file view that a source control system has of the xml. You can either put some smarts in the visual -> xml layer that preserves ordering within what is nominally non order specific data, or put some smarts in the xml - source control layer. Both have their weaknesses. The contract for a visual designer persistance is that it can correctly save and reload changes, not generally that it needs to preserve whatever changes have occurred external to the designer. Adding a merge friendly contract to the persistance routines for a visual designer isn't a particularly easy thing to achieve (in my mind at least, and this is backed up by anecdotal evidence of SSIS, SSAS, ...). Using a flat file to represent structured data is the first impedance mismatch that needs to be addressed. Perhaps there is a data + delta format that would make more sense here? Smarts in the source control is another way to handle this. Let's say in some source code, I make a change to a line in a method (for instance I correct an off by 1 bug) and checkin v2. Next I move that method before the previous method in the file and check in v3. Diffing v1 to v3 doesn't give me a real indication of the v1 to v2 changeas the v2 to v3 changes are more obvious and noticeable in the diff. Smarts in source control interpretation of the 'source' that is being stored would allow that kind of situation to be more opaque. Do any source control systems do this at present?

Tom Isaacson commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 09:17:21 GMT

@Chris: I don't know - haven't installed it yet but I have the DVD ready for a rainy day. It's possible this doesn't affect PC developers but we're doing builds for multiple WinCE devices (using different SDKs) and it's a major pain. I also found a bug which corrupts the .vcproj file when you edit the preprocessor settings but Microsoft can't recreate it - odd how it happens to me on a daily basis!

Frans Bouma commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 09:14:04 GMT

@Oren: every o/r mapping file has elements which refer to other elements by name. there can be a situation (e.g. with complex inheritance scenarios) where person A removes or changes elements in such a way that his file is still correct but when merged with another file which is also a changed version of the SAME parent, you'll get merge conflicts. That's where the gripe is all about I think: a diff tool can only go so far before it has to give up because it has to decide between two (or more) options and the user now has to fix it manually. With reshuffled XML this is hard to do. You don't sell me the story that making two copies from the same nhibernate mapping file, changing things at different places in these 2 files will never result in a merge conflict. That's not something bad about nhibernate, I just used that as an example. We use a binary file, which is also a pain in scc. (we therefore will move to a text dsl soon) I think the main point is: HOW should XML be merged in a SCC system? I think Driessie gave a good hint: with an XML diff tool. So, a SCC shouldn't threat XML files as text but as XML data, and should use the appropriate diff tool to merge them. After all, using an XML diff tool, merging XML is easy, with a text-diff tool it can be a pain. This goes further: merge conflicts arent solvable in a texteditor when the text is xml. Sure simple name changes are, but if the xml differs a lot, especially when elements refer to other elements (relationbetween entities based on a field which doesnt happen to be there in the merged data, -> relation has to go as well, but because that relation goes, the inheritance hierarchy has to go...), merge conflicts are only solvable with a tool which is made especially for xml merge conflicts, as it understands that the text at hand is XML, i.e. structured data, not random ascii.

flukus commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 02:54:57 GMT

Even if you use the checkout-edit-checkin scenario, what if a bug comes up. If it was a minor change which caused the issue how do you find the minor change when 70% of the file has changed? Makes me wonder what it would be like to compare a diff on word generated OXML file versus a Open Office generated ODF file....

naraga commented on Source control is not a feature you can postpone to vNext

Sat, 19 Apr 2008 00:33:34 GMT

well this always happens if you choose "wizard" way of work. but i'm not sure if world without wizards would be better place to live. what we can do now? use inteligent xml merge tools if only formatting and ordering is problem. what tool vendors can do? split files into multiple parts (fundamental content, layout stuff, other unimportant fluff) so we can merge only fundamental part. and yes i must confirm that most companies work in checkout-edit-checkin mode...

AWolf commented on Source control is not a feature you can postpone to vNext

Fri, 18 Apr 2008 13:40:11 GMT

Oh crap.......Not Oslo......Dam....Crap Whatever.

Alex Simkin commented on Source control is not a feature you can postpone to vNext

Fri, 18 Apr 2008 13:05:58 GMT

@Jan "So new objects would be placed on some default locations" How do you know that new objects should be placed on the diagram first of all. By having one diagram for all objects in the system? "Classes and diagrams should be in sync..." Exactly. So, if object is not on the diagram, should it ba added to diagram or deleted (because it is deleted from diagram). I use "diagram" as an example, you can imagine some UI designer that cannot be considered as secondary tool, it is primary tool to create something, but with limitations that force you to retort to code editing. (This is real life).

Jim commented on Source control is not a feature you can postpone to vNext

Fri, 18 Apr 2008 08:16:57 GMT

Why do you still use .NET or Microsoft specific technologies then? Based on the Java SDK code that I've read, Sun and Java developers are far more competent.

Jan Limpens commented on Source control is not a feature you can postpone to vNext

Fri, 18 Apr 2008 03:15:37 GMT

@ Alex I fail to see the problem, because the only part that could be out of sync is visual meta data (because that is what is not versioned). So new objects would be placed on some default locations defined by the program or removed if deleted. Classes and diagrams should be in sync due to the diagramming tool (as you suggest). If not, it is the task of the designer to update itself from the concrete classes (the other way would be automatic, wouldn't it?). Maybe I am missing something here...

Alex Simkin commented on Source control is not a feature you can postpone to vNext

Fri, 18 Apr 2008 02:11:09 GMT

@Jan "should be persisted as a per-user preference" Then solve this chicken/egg problem: When you change class diagram, the designer changes generated classess, when you change generated classess, the designer updates diagram. All nice and peachy when you are on your own in the Visual Studio. Now you have checked out designer file and generated classess from the SCM. How do you validate the check out? Do you update diagram or classess?

Jan Limpens commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 22:50:43 GMT

Alex: probably the ordering of boxes in the designer (which has no implication to the generated classes) should be persisted as a per-user preference and not being versioned. Even if it was this should be easy to version. The problem arises with carelessly created xml (usually xml serialized objects) that has no special order and random formats. If changing y="250" to y="251" leads to lots of linebreaks, reordered class elements, this can become unmergable.

Ayende Rahien commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 22:35:12 GMT

Alex, That issue is a classic conflict, you have to decide what to do. And that scenario, FYI, completely breaks in that product.

Jake Scott commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 21:56:06 GMT

The problem is the designers use xaml, if you move a object on your diagram, the xaml is changed dramatically. Therefore when two developers try to merge there changes (eg linq to sql designer) you have merge hell. I choose on my latest project just to use sqlmetal.exe instead of the horrible designer.

lmchen commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 21:11:44 GMT

Kind of checken and egg queation. If a language is design to be not Source Control friendly. I don't understand why this is a Source Control System's fault? I don't think Source Control is any friendlier to LISP or PROLOG or T-SQL language files. Source Control are special nice to procedual language like C, BASIC, PASCAL. (That's why CVS, preforce, are all line base diff. -- They are easier to implement) I think I miss something here -- Are you claim that XML is also a procedual language so Source Control system must do a "same" job as they did for C, C++, Basic, pascal?

Alex Simkin commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 19:53:49 GMT

@Ayende "Alex, Yes, it has a designer." Oh, perfect... Now answer the following question: You have created a class diagram and checked it in. Two other developers checked out diagram and moved boxes around (doesn't affect code generation, so nothing changed but designer file). Now they are checking in their files and asked to merge their changes... Assuming that they completely understand file layout and it is not mixed up (sorted alphabetically :P ). How do they do it if one wants base class on the left and the other wants base class on the right (and I prefer them on top)?

Oran commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 19:43:23 GMT

Exactly, exclusive checkouts are not the right solution to their lack of foresight, but it's unfortunately the default solution most Microsofties will think of because that's the style of source control everyone uses there. Even if they dogfooded it, they would dogfood it with exclusive-checkout blinders on. :-(

Ayende Rahien commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 18:45:27 GMT

Darius, No, it is not a source control system. It is a product that cannot be used in source control. Tom, There are a LOT of stuff from MS that do that. This is broken, period. Frans, NH mapping files are not randomly shuffled each time you edit them. If you edit something, it is a local modification. If you edit something using MS approach, 70% of the file have changed. This is not an issue with XML, it is an issue with the way they are using XML. El, About Linq to SQL, no, it doesn't have this issue. Will, This is a problem in a lot of MS products. It is specifically an issue with a product that I saw that saved its files in such a way that make source control useless. Frans, In NH, you don't need to reference other entities in a way that is broken on each change. If you make a modification, it is local and mergable. I was working with a domain that had > 10,000 entities across ~700 databases, no issues. Alex, See the rest of the stories in the comments for clarifications. There is zero reason this can't work, it is just made broken. Specifically, Driesie does a good job describing the problem. Glyn, Yes, that is the problem I am talking about. Alex, Yes, it has a designer. Chad, The first step, get your source control story right. This is about as basic as it can get. After that, we can talk. The other steve, There is not issue with XML itself, but the way they save stuff is by randomly moving things around. A simple change affect the entire file. Can't code review that, can't merge that, can't branch that, broken. Oran & Eric, Actually, checkout / edit / commit was the proposed "solution" to this issue. It doesn't work, because branches are actually useful.

Mr_Simple commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 18:36:00 GMT

It ain't just Microsoft, throw corporate America, Google, Sun, and open source in there too. The programmers at these outfits aren't any better or worse than anyone else - we just wish they would be better. Bottom line, protect yourself with comments, asserts, logs, and source control. To heck with the other guy because no doubt you'll be straightening out his mess, but he won't be working on your mess because there is no mess.

Miki Watts commented on Source control is not a feature you can postpone to vNext

Thu, 17 Apr 2008 18:13:40 GMT

That is the exact reason I've stopped trusting and using .resx files. I'm developing my own layout file, where at least there it won't shuffle the file all over the place, making me lose entire days of work during the merge.