How to contribute VCSInfo back end for fossil

How to contribute VCSInfo back end for fossil

[Mike Meyer]

Hello,

Sorry if this is the wrong place, but neither google nor
hand-examining the zsh sites turned up a place for such submissions...

Anyway, I wrote a vcs_info backend for the fossil scm
(http://fossil-scm.org/). I'd like to donate the code back to the zsh
community, but don't see an obvious way to do so.

You can find the source repository at:
https://mwm@chiselapp.com/user/mwm/repository/vcs_info You can either
clone that (with fossil, of course) or download a zip archive from
there (Login, use the captcha as password for anonymous, timeline, top
link in timeline, ZIP archive at the bottom of the overview) or let me
know what I should do to submit them.

Oh yes - not subscribed to the list, so please make sure replies come
back to me as well as the list.

     Thanks,
     <mike

-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: How to contribute VCSInfo back end for fossil

[Frank Terbeck]

Mike Meyer wrote:
> Sorry if this is the wrong place, but neither google nor
> hand-examining the zsh sites turned up a place for such submissions...

This is exactly the right place.

> Anyway, I wrote a vcs_info backend for the fossil scm
> (http://fossil-scm.org/). I'd like to donate the code back to the zsh
> community, but don't see an obvious way to do so.

Great. I've briefly looked at the code and it seems clear enough. I'd
like to commit the following:


diff --git a/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil b/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil
new file mode 100644
index 0000000..5515283
--- /dev/null
+++ b/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil
@@ -0,0 +1,13 @@
+## vim:ft=zsh
+## fossil support by: Mike Meyer <mwm@mired.org>
+## Distributed under the same BSD-ish license as zsh itself.
+
+setopt localoptions NO_shwordsplit
+
+[[ $1 == '--flavours' ]] && return 1
+
+VCS_INFO_check_com ${vcs_comm[cmd]} || return 1
+vcs_comm[detect_need_file]=_FOSSIL_
+VCS_INFO_bydir_detect . || return 1
+
+return 0
diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil b/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil
new file mode 100644
index 0000000..4568b64
--- /dev/null
+++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil
@@ -0,0 +1,37 @@
+## vim:ft=zsh
+## fossil support by: Mike Meyer <mwm@mired.org>
+## Distributed under the same BSD-ish license as zsh itself.
+
+setopt localoptions extendedglob
+local a b
+local change changed
+local action merging
+local -A fsinfo
+local -xA hook_com
+
+${vcs_comm[cmd]} status | while IFS=: read a b; do fsinfo[${a//-/_}]="${b## #}"; done
+fshash=${fsinfo[checkout]%% *}
+changed=${(Mk)fsinfo:#(ADDED|EDITED|DELETED|UPDATED)*}
+merging=${(Mk)fsinfo:#*_BY_MERGE*}
+if [ -n "$merging" ]; then
+   action="merging"
+fi
+
+# Build the revision display
+fsrev="${hook_com[hash]}"
+
+# Now build the branch display
+zstyle -s ":vcs_info:${vcs}:${usercontext}:${rrn}" branchformat fsbranch || fsbranch="%b:%r"
+
+hook_com=( branch "${fsinfo[tags]%%, *}" revision "${fsrev}" )
+
+if VCS_INFO_hook 'set-branch-format' "${fsbranch}"; then
+    zformat -f fsbranch "${fsbranch}" "b:${hook_com[branch]}" "r:${hook_com[revision]}"
+else
+    fsbranch=${hook_com[branch-replace]}
+fi
+
+hook_com=()
+
+VCS_INFO_formats "$action" "${fsbranch}" "${fsinfo[local_root]}" '' "$changed" "${fsrev}" "${fsinfo[repository]}"
+return 0



As you can see, I've removed the code that surrounded the `$fsrev'
variable. Specifically, the `fsrevformat' style and the
`set-fsrev-format' hook. They didn't add much, as you've got full access
to the same data in with the `branchformat' style and the
`set-branch-format' hook (I kept the `$fsrev' variable for clarity).

Like this, the only required documentation update would be to name
fossil among the supported systems in zshcontrib(1).

If you're okay with those changes, it would be good if you could check
whether the above code works or not - I didn't test those changes.

Regards, Frank

Re: How to contribute VCSInfo back end for fossil

[Mike Meyer]

On Fri, 18 Mar 2011 00:06:26 +0100
Frank Terbeck <ft@bewatermyfriend.org> wrote:

> Mike Meyer wrote:
> > Sorry if this is the wrong place, but neither google nor
> > hand-examining the zsh sites turned up a place for such submissions...
> This is exactly the right place.

Cool.

> As you can see, I've removed the code that surrounded the `$fsrev'
> variable. Specifically, the `fsrevformat' style and the
> `set-fsrev-format' hook. They didn't add much, as you've got full access
> to the same data in with the `branchformat' style and the
> `set-branch-format' hook (I kept the `$fsrev' variable for clarity).

That was modeled after the hgrevformat variable. If that's gone away
in later versions, then fsrevformat should go away.

I initially did this without fsrevformat. I changed it because it
seems slightly cleaner to have vcs-specific variables that control how
the revision value is presented for each vcs rather than having to
tweak branchformat for each vcs with a hash-based revision - which
seems to be required because once you shorten it, zformat can't make
it longer, so that %r has to be the entire hash, which is unwieldy.
With fsrevformat, I only have to change branchformat and the various
VCS's follow automatically, rather than having to change branchformat
for each VCS using hash-based revisions. Maybe the hook facility
solves this - I haven't really explored that.

Either way is fine with me. I just wanted to present the reason before
committing to the other way.

> Like this, the only required documentation update would be to name
> fossil among the supported systems in zshcontrib(1).
> 
> If you're okay with those changes, it would be good if you could check
> whether the above code works or not - I didn't test those changes.

They don't work. You deleted the setting of hook_com prior to setting
fsrev, which meant fsrev was set to "".  It needs to be set to
${fshash}. I think the fshash name is better, as it is the hash
string. If you want it without fsrevformat, I'll wind up pushing that
to the repo in any case, but let me know if you'd rather I email you
that version.

While I'm here - it seems that the git backend doesn't pay attention
to branchformat. Is that a bug (possibly fixed later) or intentional?

      Thanks,
      <mike
-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: How to contribute VCSInfo back end for fossil

[Frank Terbeck]

Mike Meyer wrote:
>> As you can see, I've removed the code that surrounded the `$fsrev'
>> variable. Specifically, the `fsrevformat' style and the
>> `set-fsrev-format' hook. They didn't add much, as you've got full access
>> to the same data in with the `branchformat' style and the
>> `set-branch-format' hook (I kept the `$fsrev' variable for clarity).
>
> That was modeled after the hgrevformat variable. If that's gone away
> in later versions, then fsrevformat should go away.

Mercurial really is a special case within vcs_info.

`hgrevformat' is still there. But it's there, because mercurial has
*both* a revision number (albeit only local) *and* a hash. And
`hgrevformat' was introduced to by able to control which of those (one
or both) are being used as "%r" in `branchformat'.

> I initially did this without fsrevformat. I changed it because it
> seems slightly cleaner to have vcs-specific variables that control how
> the revision value is presented for each vcs rather than having to
> tweak branchformat for each vcs with a hash-based revision - which
> seems to be required because once you shorten it, zformat can't make
> it longer, so that %r has to be the entire hash, which is unwieldy.
> With fsrevformat, I only have to change branchformat and the various
> VCS's follow automatically, rather than having to change branchformat
> for each VCS using hash-based revisions. Maybe the hook facility
> solves this - I haven't really explored that.

Actually, I'd like to have as little vcs-specific settings as possible.

> Either way is fine with me. I just wanted to present the reason before
> committing to the other way.

Okay.

>> Like this, the only required documentation update would be to name
>> fossil among the supported systems in zshcontrib(1).
>> 
>> If you're okay with those changes, it would be good if you could check
>> whether the above code works or not - I didn't test those changes.
>
> They don't work. You deleted the setting of hook_com prior to setting
> fsrev, which meant fsrev was set to "".  It needs to be set to

Right you are. I'm way too sloppy lately.

> ${fshash}. I think the fshash name is better, as it is the hash
> string. If you want it without fsrevformat, I'll wind up pushing that
> to the repo in any case, but let me know if you'd rather I email you
> that version.

Yeah, mail me. :)

> While I'm here - it seems that the git backend doesn't pay attention
> to branchformat. Is that a bug (possibly fixed later) or intentional?

Yes, that's intentional. The general idea is to do the least possible
work within a backend.

Early in vcs_info's development, there was no support for hashsums at
all. And "%r" in `branchformat' was supposed to be that short revision
number from svn or bzr, which wouldn't hurt (width-wise) if it was
attached to the branch name.

When support for hashsums was introduced, the "%i" replacement in normal
formats was added as well. It should contain either the hash or the
revision number (or the result of the special revision format's
expansion in case of mercurial, which has both). So it kind of
duplicates the information from "%r" but with the benefit of *not* being
attached to "%b" by default.

We could actually get rid of branchformat altogether and solely rely on
"%i", but I don't want to break backwards compatibility.


That being said, using fossil's hash as "%r" in a branchformat kind goes
against the "doesn't-matter-width-wise" idea of "%r". We should probably
drop the branchformat style for fossil, too, and rely use "%i". That
would be consistent with the other backends as well, then. I do realise,
that the default value of `hgrevformat' is inconsistent with that. But
that doesn't mean, that the fossil backend would have to do that too. :)

That would reduce the code of the fossil backend to something very nice
and short:


diff --git a/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil b/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil
new file mode 100644
index 0000000..5515283
--- /dev/null
+++ b/Functions/VCS_Info/Backends/VCS_INFO_detect_fossil
@@ -0,0 +1,13 @@
+## vim:ft=zsh
+## fossil support by: Mike Meyer <mwm@mired.org>
+## Distributed under the same BSD-ish license as zsh itself.
+
+setopt localoptions NO_shwordsplit
+
+[[ $1 == '--flavours' ]] && return 1
+
+VCS_INFO_check_com ${vcs_comm[cmd]} || return 1
+vcs_comm[detect_need_file]=_FOSSIL_
+VCS_INFO_bydir_detect . || return 1
+
+return 0
diff --git a/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil b/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil
new file mode 100644
index 0000000..fecf044
--- /dev/null
+++ b/Functions/VCS_Info/Backends/VCS_INFO_get_data_fossil
@@ -0,0 +1,23 @@
+## vim:ft=zsh
+## fossil support by: Mike Meyer <mwm@mired.org>
+## Distributed under the same BSD-ish license as zsh itself.
+
+setopt localoptions extendedglob
+local a b
+local changed fshash
+local action merging
+local -A fsinfo
+
+${vcs_comm[cmd]} status | while IFS=: read a b; do
+    fsinfo[${a//-/_}]="${b## #}"
+done
+
+fshash=${fsinfo[checkout]%% *}
+changed=${(Mk)fsinfo:#(ADDED|EDITED|DELETED|UPDATED)*}
+merging=${(Mk)fsinfo:#*_BY_MERGE*}
+if [ -n "$merging" ]; then
+   action="merging"
+fi
+
+VCS_INFO_formats "$action" "${fsbranch}" "${fsinfo[local_root]}" '' "$changed" "${fshash}" "${fsinfo[repository]}"
+return 0


If you're okay with that (and if it works this time...), I'd like to
commit the above.

Regards, Frank