On 12.08.2014 09:26, Alexey Neyman wrote:
>
> On Tuesday, August 12, 2014 08:33:06 AM Branko Čibej wrote:
>
>
> > So why do you need the last-changed revision of the project directory
>
> > stored in the header file? Are you distributing sources directly from
>
> > the repository, or are you using that number to identify builds? In
>
> > either case, there are better ways to do that.
>
>
>
> Sometimes, yes. Not directly from a repository but engineers sometimes
> release semi-official builds to customers.
>
>
>
> I understand that is less than ideal way (not dealing with
> mixed-revision WCs, etc.). So, I am curious what are those better ways
> you mention?
>
I'm sort of assuming a defined build (or packaging) workflow. If you
have engineers mailing binaries from their mixed-revision development
working copies to customers, all bets are off, since they might have
locally modified your version property.
One solution is to run "svnversion" as part of the package/build and
include the result in the build artefacts. Can't go into any more detail
than that, since I have no ides what your build system looks like. This
won't always perfectly identify the configuration you're building, but
at least it will give some indication of the state of the working copy,
and whether (oh horror) it includes local modifications.
> > I'd just like to point out that Subversion already has heuristics to
>
> > identify binary files. If you add a binary file to the working copy, it
>
> > will automagically get the svn:mime-type set to
>
> > application/octet-stream. There are only a few MIME types that
>
> > Subversion does not consider binary. Of course, your heuristics might be
>
> > different from Subversion's, but have you considered just looking at the
>
> > mime-type property?
>
>
>
> Yes, I've considered it, there are a few drawbacks:
>
>
>
> - First, the repository was imported from CVS and many binary files
> were not marked with the svn:mime-type properly set at the conversion
> time (most likely, because the oridinal CVS file didn't have -kb
> keyword expansion set - but that's now history). This could be solved
> by going over all the project files once and setting svn:mime-type
> explicitly, though.
>
Right.
> - Second, some of the MIME types are text even though the MIME type
> does not start with 'text/*'. "image/svg", "application/x-sh" and
> "application/xml" are a few most obvious examples that come to mind. I
> don't know how to come up with an exhaustive list of such
> "text-despite-MIME-type" types.
>
Heh, tell me about it. Subversion has the same problem, and we still
haven't found a satisfactory solution for it.
> Because of these I decided to use a separate property.
>
So you really only have to add this property on added files, right? Have
you considered using auto-props? They don't currently give you exactly
the knob you need, because we don't have an auto-prop setting for "all
binary" or "all text" files, but maybe that could solve your problem.
Especially now that, with 1.8, you can define auto-prop settings in the
repository and no longer need local configuration on every client.
(Caveat: you do need 1.8 clients.)
> > > So, to avoid modifying the transaction by pre-commit (that no longer
>
> > > reliably works in 1.7 and 1.8),
>
> >
>
> > Correction: that never reliably worked, because we never promised it
>
> > would work.
>
>
>
> We haven't noticed any issues with 1.4, 1.5 and 1.6 :)
>
"I always drive on the left side of the road, and I keep seeing all
these traffic accidents. You wouldn't believe how many bad drivers there
are out there." :)
> By the way, does SVN guarantee that such kinds of issues (full disk,
> power failure) do not result in repository ending up in an
> inconsistent state? If SVN does not offer such guarantees, it is
> pointless to require them from a post-commit script anyway.
We do try to make the repository recoverable, yes. Guaranteeing that
post-commit runs is not a priority, though.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane_at_wandisco.com
Received on 2014-08-12 09:44:09 CEST