Re: Tracking and committing back to Subversion?

Eric Wong wrote:
>>  1. file properties - such as mime type, ignores and custom properties.
>>     Linus, when I asked you about this in Dunedin, you mentioned that
>>     there is a place at the end of the directory entry where this could
>>     fit without breaking backwards compatibility.  Perhaps this could
>>     be an optional pointer to another directory node;
> Mostly ignore-able, imho.  svn:executable is the one that makes the most
> sense (and is easiest) to support.
  [...]
> svn:keywords: I don't think there's a way to disable this like there
> is with CVS, is there?  keywords are evil imho.
> I don't use or know much about the other properties...

Right, but it is also possible to hang directory or file properties,
with any name, off any file or directory.  It is often important to
at least preserve or be able to update these when dealing with some SVN
repositories, where people are using them for their own purpose.

Perhaps a "standard" mapping to dotfiles would be the best solution
then.  A .svnprops file or something like that.

>>  2. "forensic" file movement history - as opposed to the uncached,
>>     (and unversioned), automatic "analytical" file movement history.
>>
>>     It would be easy for a tool to provide 100% interface compatibility
>>     with SVN client/SVK using properties, but properties that hang off
>>     the head rather than the file itself (so that they don't stuff up
>>     the ability to merge identical trees reached via independent
>>     paths).  SVN calls these "revision properties".  If a good
>>     convention is adopted for this, it could be used as a nice way to
>>     supplement git's automatic analysis of the revision history.

> Just parsing the output of diff-tree -C and marking them in SVN as
> copies/renames should be sufficient for letting SVN do its thing.
> 
> Doing this kind of file movement history on the git side sounds like
> overkill to me.  I was a _huge_ fan of logical file-identities in GNU
> Arch in the past, but the complexity destroyed it from both a UI and
> performance perspective.

Right now, tagging gets an exemption from this requirement, as does the
extra state required by tools like StGIT.  I think this could be
generalised to support this kind of application; however we will see
whether this has any real effect or just operational side effect (eg, to
make sure renames are tracked correctly then commit before changing the
copied version, etc).

Sam.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html