On Fri, Nov 5, 2010 at 7:02 PM, Richard M Willis <RichardW_at_pulsar-pm.com>wrote:
> > There is.
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks
> >
>
> Yes, that is the client-side hooks what I mentioned earlier. As I said, it
> doesn't work for me. I expect just to point that hook at some batch file or
> other (which may or may not be something that has come out of the registry)
> but it just flashes a DOS box and does nothing. I know these batch files run
> with an empty environment, but it should do *something* surely.
>
> Can someone explain what the "directory" bit is for ? I don't want to
> commit myself to people checking out to a particular directory (even if I
> said C:\ then that would preclude people checking out to other drives).
>
> <later>
> Oh, great ! I've just realised that client-side-hooks are now
> machine-global; I want them per project !
> </later>
>
> I'm pretty sure CVS has a commit-once-but-never-version option for each
> file. Is my memory wrong on this ? If it isn't, and SVN was developed as "a
> better CVS", why on earth was this simple-to-implement feature missed out.
>
> Currently, I have multiple people who copy "the project" from a file server
> into some directory. They build. They make changes. They submit it back to
> the file server. All I want to do is to replace the "file server" with
> subversion (or any version management system). If they are going to have to
> remember to do a "run this batch file" or setup some obscure extension to
> TSVN to get it to work, they aren't going to accept it.
>
How often is a new build environment created on a given machine? Is the
process of setting up a new environment documented anywhere?
Could you not :
a) include template files (e.g. foo.xyz.template0, and add the .xyz
extension to the svn:ignore property
b) Create a standalone script that everyone *must* use to checkout/create
the new environment. This script copies the foo.xyz.template files to
foo.xyz
Because the script is used to checkout, rather than TSVN itself, the users
should see no difference. You could even launch the SVN checkout dialog from
within the script itself, so it appears like TSVN is doing all the work.
> I realise that, in part, what I am trying to do is to make TSVN accommodate
> the stupidity of our build environment. If we were able to do it properly,
> with make files and stuff, this would not be an issue.
>
> Actually, the original problem is only the tip of the iceberg, I have other
> things that I expect (T)SVN to do, such as deem a file "not changed" if just
> some absolute path has changed (HWB need absolute paths and different
> developers will checkout to multiple directories). Having been informed last
> night that custom differs can't do this, it seems I'm stuck all ways.
>
You expect TSVN to be able to see a file as 'not changed', when in fact it
has? I think that will be more trouble than it's worth.
> This business about "security" and people checking in rogue scripts just
> won't happen in my environment and if SVN/TSVN had a simple "perform a
> simple copy" on checkout (that could be done server side), there wouldn't be
> any need for generic scripts, and thus no security issues (for me).
>
It might not happen in yours, but that does not mean it will not happen
somewhere.
> I'm running Slik VisualSVN Server as a server. I wonder if this can do
> anything helpful for me.
>
> Maybe I should go with the DVCSen trinity: bzr, git, hg. I don't really
> want the distributed business but they seem a lot more accommodating.
>
Possibly, but I wouldn't hold my breath. When I investigated them, I found
them to be less useful than SVN. YMMV, though.
Cheers,
Daniel B.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2679128
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-11-05 11:49:37 CET