Timothy J. Weber wrote:

> Sure.  It's just that, in Subversion, branches are normally placed in a 
> different path, like this:

Ah... makes sense. Interesting... Just to illustrate how difficult it is to
compare the features without an intimate knowledge of all involved systems
:)

>> Similarly with the binary files... how do you handle, say, CAD files in
>> the repository?
> 
> Binary files don't require anything special in Subversion... they're
> diffed using a binary diff algorithm, and the binary diff is what's
> stored and transmitted. 
> 
> Is that what you mean?

No, I mean something different. It's actually not the quality of being
binary, it's the quality of being non-mergeable. There are mergeable binary
files (if you have the proper tools) and there are text files that have a
structure that's so complex and/or are generated automatically that they
are functionally non-mergeable. I'm talking here about the non-mergeable
files of either type.

If you have such files in the repo and potentially different people working
on them, it's very handy to have the repo enforce that always only one is
working on them.


>> Merge points are about the following... [...]

> Hm... I don't do that a lot, so I'm not sure... but Subversion lets/makes
> you "resolve" changes against a given revision before committing them,
> and I think it does remember what you last resolved to. So I think you
> can resolve but not commit, and then resolving again later will do what
> you're talking about.

What I'm talking about is something similar to what is in the svn roadmap
as "merge tracking". 

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist