In the meantime ... you might want to consider writing a wrapper script
(svnco.sh?) for this that prepends $SVNROOT (or whatever) to the passed-in
module name. You really only need this at checkout-time, that should
simplify matters.
As to the general tone of this discussion, that's the price you pay for
using (or wanting to use) a product that has - for all intents and purposes
- only been out for a couple of weeks. If you and/or the people you work
with are that particular about things like this, you should probably stick
with CVS for a little while longer and wait for Subversion to mature a
little bit more. Or convince your employer to pay for a commercial SCM so
you have some leverage in demanding solutions to "obvious" holes in
functionality and/or design. As for Subversion, a lot of these design
choices have been heavily debated over the course of development, both on
merit and priority, and getting involved back then, rather than raise issues
now, might have gotten you somewhere, and this whole thing would've never
become the problem that it seems to be to you right now ... not saying I
think that's what you should have done, just saying that's how some things
make it into a 1.0 release and others don't ... it pays to get involved
early. I think it's great you're volunteering to do the work now, but I'm
guessing you'll have to get in line just like everyone else ...
As to the prioritzation in Subversion, it seems to me the focus has
consistently been on doing stuff that makes SVN work. Especially in these
types of tools, I wouldn't want to see it any other way. Usability means
nothing if the thing can't be trusted ...
Personally, I'm a pragmatic in that I look at a tool and ask myself "does
this do what I need it to do today?" If the answer is no, I'm likely to look
elsewhere, unless I feel I can sell the limited amount of pain involved in
waiting for the gap to close ... maybe moreso than with any other software
development tool, SCM is the one you want to get right. I love tinkering
with the latest and greatest as much as the next guy, but the phrase "if it
ain't broken, don't fix it" does come to mind. What I guess I'm trying to
say is that you probably should do a bit more thinking on the short-term
implications of changing to Subversion, and shouldn't speculate on how
quickly certain wrinkles will get ironed out. I would also say that the
$SVNROOT issue is something that is so trivial to get around (i.e. write
your own wrapper script), that IMHO you would be wiser to just log it as an
enhancement request and move on. There's bigger fish to fry ...
just my $.02
Rob
> -----Original Message-----
> From: TBrowder [mailto:tbrowder@cox.net]
> Sent: Thursday, March 04, 2004 7:14 PM
> To: users@subversion.tigris.org
> Subject: Re: Re: Wish List (Revisited)
>
>
> ----- Original Message -----
> From: "David Waite" <mass@akuma.org>
> To: <users@subversion.tigris.org>; <kfogel@collab.net>
> Sent: Thursday, March 04, 2004 2:02 PM
> Subject: [work] Re: Wish List (Revisited)
> > > Are you using "users" to mean "I"? :-)
> > >
> > > Seriously, I haven't heard of this being a problem until now, but
>
> A few more points:
>
> The folks on this list are serious *nix folks, but my
> co-workers tolerate
> *nix to get their job done. The majority of them use ONE
> repository for the
> data they produce, and the repository location may change
> from time to time.
> Complicating the command line complicates their life and my
> job is to keep
> the system minimally intrusive for them. (But yes, David, I'm
> also a user
> who likes the CVSROOT feature. I use about four different
> repositories and
> change the definition of CVSROOT with shorthand aliases under
> tcsh shell.)
>
> The history -T from CVS gives a date-sorted list of tags
> associated with a
> module. It's invaluable when we need to see a history point
> when a product
> went out the door. And we can retrieve its state at that
> point by the tag
> name. (And it can't be easily changed.) I want to do the
> same thing with
> subversion. I don't care to see the directory tree polluted
> with lots of
> names just to have tags at milestones.
>
> The .svnignore file capability would, at the least, ease my job when I
> transform my CVS databases to subversion.
>
> And truly, is the command line parsing going to be much more
> complicated by
> these three featues? Is subversion for the developers? Or for the
> potential users, too?
>
> Again, I'm happy to try to make the necessary changes, but
> I'm frustrated
> that no one else has seen the utility of them.
>
> Tom Browder
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 5 16:45:40 2004