On Thu, Sep 02, 2010 at 11:27:07AM +0300, Daniel Shahaf wrote:
> Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:13:00 +0200:
> > On Wed, Sep 01, 2010 at 06:37:08PM +0100, Julian Foad wrote:
> > > This may be off topic, but I'm wondering whether Git has defined such
> > > operations on directories fully or at all, since it doesn't version them
> > > explicitly. I mean, can you tell the difference between "add empty file
> > > A" and "add empty dir A"? I could go and look, but haven't time today.
> > > If yes, great; if it doesn't, we'll have to invent syntax extensions to
> > > do it. (I'm recalling that the goal of this work is we want Subversion
> > > diffs to be able to support all valid Subversion changes, and we chose
> > > Git format as a basis for supporting that. We don't want to constrain
> > > ourselves to only the operations that Git supports.)
> >
> > Not supported at the moment:
> >
> > $ svn mkdir X
> > A X
> > $ svn status
> > A X
> > $ svn diff
> > $ svn diff --git
> > $
> >
> > Suggestion:
> >
> > $ svn diff --git
> > Index: empty
> > ===================================================================
> > diff --git a/trunk/empty b/trunk/empty
> > new directory mode 10644
>
> IIRC trailing slashes on "empty/" were suggested on IRC, what was the
> conclusion about that?
I didn't follow that one (atleast I don't recall following it) but will
stay tuned for the resolution of the discussion.
> > E.g., just changing the 'new file mode 10644' line to mention directory
> > instead. Haven't investigate what changes would be needed in the diff
> > editor.
>
> By the way, are we just influenced by Git's format, or are we looking
> for some degree of interoperability? Consider adding a symlink:
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?
Note that we don't yet perform any symlink operation when applying a
path with svn:special set.
> [[[
> ### with git (in $wcroot/trunk/):
> diff --git a/trunk/bar b/trunk/bar
> new file mode 120000
> index 0000000..1910281
> --- /dev/null
> +++ b/trunk/bar
> @@ -0,0 +1 @@
> +foo
> \ No newline at end of file
>
> ### with svn (in $wcroot/trunk/):
> Index: bar
> ===================================================================
> diff --git a/trunk/bar b/trunk/bar
> new file mode 10644
> --- /dev/null (revision 0)
> +++ b/trunk/bar (working copy)
> @@ -0,0 +1 @@
> +link foo
> \ No newline at end of file
>
> Property changes on: trunk/bar
> ___________________________________________________________________
> Added: svn:special
> ## -0,0 +1 ##
> +*
> ]]]
Daniel (Näslund)
Received on 2010-09-02 11:05:08 CEST