[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

client-side hooks ? Re: how to artificially create local "Conflicted" state ?

From: Yakov Lerner <iler.ml_at_gmail.com>
Date: Wed, 30 Apr 2008 08:17:32 +0300

On Wed, Apr 30, 2008 at 1:10 AM, John Niven <jniven_at_bravurasolutions.com> wrote:
> > -----Original Message-----
> > From: Yakov Lerner [mailto:iler.ml_at_gmail.com]
> > Sent: Tuesday, 29 April 2008 19:20
> > To: users_at_subversion.tigris.org; Puneet Lakhina
> > Subject: Re: how to artificially create local "Conflicted" state ?
> >
> > > > How can I artificially create the local "Conflict" state on the
> > > > working
> > > file,
> > > > without doing any checkins on any computer ? Sort of opposite to
> > > > 'svn resolved'. How ?
>
> > > I dont think there is a direct way of doing it. This would involve
> > > some sort of a hack by modifying .svn/entries file for this
> > particular
> > > directory. In conflicted state the entries file contains
> > entries for
> > > filename.rPREV filename.rHEAD and filename.mine
> > > >
> > > > The purpose is to prevent accidental checkin of
> > temporary/debugging
> > > > changes in the file. Attempt to checkin should cause svn
> > error, just
> > > > like attempt to checkin the file in Conflicted state is refused.
> > > >
>
> > In Linux/Unix, I do have a solution for protecting from
> > accidental checkin -- I make local file to a become symlink
> > -- then 'svn ci' dies with "Special state changed" error.
> > That's nice trick.
> >
> > But On Windows .. on windows I am still searching for the solution.
> >
> > The hacking the .svn/entries you mentioned looks promising,
> > I'll investigate it.
>
> I'm surprised other people haven't haven't cautioned you about hacking
> /svn/entries, but it sounds like a horrible way to quickly mess up your
> working copy.
>
> Another approach might be to have a pre-commit hook that checked for the
> existence of a certain string, and blocked the commit if the string was
> present in a file. Then you could add the string to the beginning of
> any file you were debugging, something like
> "//__DEBUGGING__DO_NOT_COMMIT__". Human- and machine-readable, so very
> clear to anyone what it does. You'd possibly want to have the hook
> script only check the first line of each file, so as not to slow down
> commits too much.

Yep, for those who can modify the server, this is possible solution.

I do not have access to the server other than checkin/checkout.
I am looking for client-only solution. If svn had client-side hooks
though ......

It would be nice if svn had client-side hooks btw, would be helpful.
Any plans to add client-side hooks to svn ?

Thanks
Yakov

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-30 07:17:56 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.