On Thu, Sep 02, 2010 at 11:03:36AM +0200, Daniel Näslund wrote:
> We have two goals I think:
> i) Implement a format that is interoperable with git and mercurial and
> possible other vcs tools that choose to implement the git extensions
> to the unidiff format.
> ii) Adjust the format dictated by the git unidiff extensions to allow us
> to describe svn-specific features such as properties, versioned
> dirs and copies from a specific revision. Those are the ones that
> immediately comes to mind. Please fill in if you have more
> suggestions on what the format should include!
>
> As for symlinks, svn has the (in my opinion) ugly solution of storing
> the information in an svn:special property. So we have a specific svn
> way of specifying symlinks. Originally it was my intention to only use
> the svn:special property. For me, the goal of interoperability is clearly not as
> important as us having a format that works for svn. If I were to choose
> between introducing additional complexity for providing interoperability
> or drop that feature (i.e. git symlinks) I would choose the second by
> instinct. But maybe the community values i) more than I do?
I'd say that if git already has a way to represent a concept in its
diff format, we should strive to represent the same thing in the same way.
Because the format isn't standardized, we must try to adhere to the
current de-facto standard as much as possible to avoid incompatibilities.
Regardless, we'll probably see compatibility problems sooner or later as
time goes by and each of the git, hg, and svn teams amend the output of
their diff command. But any known diviation should at be documented and
eventually fixed.
So I think we should aim for eventually representing symlinks just like
git does. svn patch can interpret the special "symlink" file mode and
create a symlink the svn-way. But this doesn't need to happen for 1.7.
svn patch can easily interpret both the git-way and the svn-way of
representing symlinks. So we can simply change the way svn diff prints
symlinks later, even in 1.8. svn diff could encode the symlink once in
the git diff header and once as a property, to stay backwards compatible.
For now, an svn symlink will show up as an empty file when the patch is
applied with git. I don't think that's a huge problem. Nice to have, but
not release critical for Subversion.
> Note that we don't yet perform any symlink operation when applying a
> path with svn:special set.
We should though. I've filed an issue about that:
http://subversion.tigris.org/issues/show_bug.cgi?id=3697
Stefan
Received on 2010-09-02 13:26:19 CEST