[scm] Use case: Keep the local copy clean

[Matthieu Riou <ma...@offthelip.org>]

Hi,

A recurrent problem with both CVS and Subversion is the presence of special
files all over in your local copy. After more than 8 years of development
with either, I've learnt to *always* remember removing the .svn directory
when I copy whole trees to different locations. Well, almost always... :)
It's just a very small mistake that I believe every single developer using
one of these tools has done at least one time in his life, with sometimes
very weird results.

Aditionnally it makes cohabitation with non-SCM-aware scripts very
difficult. You always need to find a way to get these directories ignored.
Even a simple grep will return you false positives and forces you to add the
famous '| grep -v svn' (or use ack).

Ideally you should have a single file/directory either at the root of your
working copy (approach chosen by bzr and hg), in your home or in a
configured configuration directory specific to the SCM. Changing this in SVN
would be a big challenge because it's inherently tied to the way local
repositories are stored.I guess that would pretty much force us to redevelop
the whole client side but maybe there are other, easier solutions I haven't
thought of.

Cheers,
Matthieu

Re: [scm] Use case: Keep the local copy clean

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Wed, Feb 27, 2008 at 9:54 AM, Matthieu Riou <ma...@offthelip.org> wrote:
>  Ideally you should have a single file/directory either at the root of your
>  working copy (approach chosen by bzr and hg), in your home or in a
>  configured configuration directory specific to the SCM. Changing this in SVN
>  would be a big challenge because it's inherently tied to the way local
>  repositories are stored.I guess that would pretty much force us to redevelop
>  the whole client side but maybe there are other, easier solutions I haven't
>  thought of.

http://svn.haxx.se/dev/archive-2007-01/0522.shtml

http://subversion.tigris.org/issues/show_bug.cgi?id=525
http://subversion.tigris.org/issues/show_bug.cgi?id=2539

http://svn.collab.net/repos/svn/trunk/contrib/client-side/wcgrep

It's been talked about for years and everyone agrees that it'd be good
to have, but no single person has ever thought it worth implementing.
Dave Anderson came closest, but then real life intervened; so nothing
came out of his posting.

Patches to Subversion are certainly welcome.  We all know *how* to do
it, but we've consistently felt there are more important things to
work on.  -- justin

Re: [scm] Use case: Keep the local copy clean

["Roy T. Fielding" <fi...@gbiv.com>]

On Feb 27, 2008, at 6:51 PM, Matthieu Riou wrote:

> The problem when you start using tools like wcgrep is that you end  
> up having
> to recode almost all the command lines utilities provided by your  
> OS. After
> grep there's find, then there's sed, then there's copy, ... You get  
> the
> idea.

wcgrep is just an overly complicated shell script. You can do just as
well with a simple shell alias like (in tcsh):

alias foo 'find . -name .svn -prune -o -type f -print0 | xargs -0 \!*'

which will then allow you to do

    foo egrep -HnI Roy
    foo wc
    foo head -10

and so on.

....Roy

Re: [scm] Use case: Keep the local copy clean

[Matthieu Riou <ma...@offthelip.org>]

On Wed, Feb 27, 2008 at 4:49 PM, Justin Erenkrantz <ju...@erenkrantz.com>
wrote:

> On Wed, Feb 27, 2008 at 4:25 PM, Jukka Zitting <ju...@gmail.com>
> wrote:
> >  Finally, Justins point about fixing Subversion is also a valid future
> >  solution. It seems like there's a good idea on how to fix this and it
> >  just needs someone to do it.
>
> For whatever little it's worth, I pointed out this set of threads to
> the SVN devs.  A few mentioned that they'll likely be making it a
> priority to revamp libsvn_wc to have centralized metadata/text-bases
> after 1.5.0 is out.  (If we stick to our typical stabilization window,
> it probably means we're talking June before 1.5.0 is final; but trunk
> may get a bit disruptive a little bit before that once we enter RCs
> around late April/early May.)  But, if such a feature means that much
> to folks here, I wouldn't let that stop you from contributing now.
> However, getting merge tracking done right and out the door has been
> the priority for far too long amongst most SVN devs; so we may see a
> huge backlog of improvements once 1.5 gets out.  -- justin
>

Good to know, thanks for the feedback.

The problem when you start using tools like wcgrep is that you end up having
to recode almost all the command lines utilities provided by your OS. After
grep there's find, then there's sed, then there's copy, ... You get the
idea.

My C foo is a bit rusty, Ruby got me spoiled, but I'll try to see if I can
dive into the code.

Cheers,
Matthieu

Re: [scm] Use case: Keep the local copy clean

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Wed, Feb 27, 2008 at 4:25 PM, Jukka Zitting <ju...@gmail.com> wrote:
>  Finally, Justins point about fixing Subversion is also a valid future
>  solution. It seems like there's a good idea on how to fix this and it
>  just needs someone to do it.

For whatever little it's worth, I pointed out this set of threads to
the SVN devs.  A few mentioned that they'll likely be making it a
priority to revamp libsvn_wc to have centralized metadata/text-bases
after 1.5.0 is out.  (If we stick to our typical stabilization window,
it probably means we're talking June before 1.5.0 is final; but trunk
may get a bit disruptive a little bit before that once we enter RCs
around late April/early May.)  But, if such a feature means that much
to folks here, I wouldn't let that stop you from contributing now.
However, getting merge tracking done right and out the door has been
the priority for far too long amongst most SVN devs; so we may see a
huge backlog of improvements once 1.5 gets out.  -- justin

Re: [scm] Use case: Keep the local copy clean

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Feb 27, 2008 at 7:54 PM, Matthieu Riou <ma...@offthelip.org> wrote:
>  A recurrent problem with both CVS and Subversion is the presence of special
>  files all over in your local copy.

Not really a use case, but a good point anyway. The actual use case
that suffers from this would be batch-processing the working copy.

Perhaps we could add some documentation pointing to ways how to avoid
the problems with the special files and to tools like wcgrep that
Justin pointed out.

Alternatively, client tools like git-svn could probably avoid this
issue, but I'm not sure what all the tradeoffs are.

Finally, Justins point about fixing Subversion is also a valid future
solution. It seems like there's a good idea on how to fix this and it
just needs someone to do it.

BR,

Jukka Zitting