When we first considered moving to Subversion, we had heard from
Collabnet representatives that Subversion didn't have "true renames". I
wondered a little about what this meant, but kind of thought, I don't
care too much how they do it, just so the functionality is there.
If I had heard that the current implementation of renames can and
probably will lead to code loss (from the latest revision), my reaction
would have been much different. To me, probably the first rule of source
code management is "thou shalt not lose code".
At this point we have adopted it as our standard tool, moved
applications to it, bought 24x7 support, etc, so we are committed and
will have to figure out how to avoid losing code.
Until this functionaly is fixed, it would be great if the Subversion
gurus out there could put together a set of pointers, guidelies,
scripts, anything, etc, to help avoid this problem.
Thanks,
Chuck
> -----Original Message-----
> From: Morel, Jacques [mailto:Jacques.Morel@sabre-holdings.com]
> Sent: Thursday, April 12, 2007 4:22 PM
> To: Karl Fogel
> Cc: users@subversion.tigris.org
> Subject: RE: Subversion 1.5
>
>
> Thanks Karl for the quick answer.
>
> Even though a scientific feedback process is hard, it seems
> that the current management could be easily improved. I truly
> believe that a key element to have your user base engaged and
> therefore make your product better is to communicate with
> your users and make sure they know they have been heard. Most
> of them will then understand your prioritization decisions
> and keep up with it even though they may not get what they want.
>
> I am not sure I am well equipped to manage such a consortium
> and even if I was willing to do it (I may be foolish enough
> to attempt it ;-) I don't have the time right now. I would
> gladly fund part of the work though. I could try to have my
> company sponsor part of it (unlikely until we standardize on
> subversion which is unfortunately made more difficult by the
> absence of true
> renames...)
> Has this issue been researched enough to give a high level
> estimate? Do you have any idea of how much effort is
> required? How much would it take to have a developer assigned
> to it? I promise that these figures won't be used for any
> negotiation (so please feel free to respond privately if you
> prefer ;-)
>
> Jacques
>
> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@red-bean.com]
> Sent: Thursday, April 12, 2007 3:08 PM
> To: Morel, Jacques
> Cc: users@subversion.tigris.org
> Subject: Re: Subversion 1.5
>
> I sympathize with your desire for some kind of scientific
> process of requirements gathering, but I don't think the way
> popular open source projects work is conducive to that kind
> of process. True, we used a formal requirements-gathering
> process for merge tracking, but that's because CollabNet funded it!
>
> The developers here tend to set priorities according to:
>
> - What users seem to need done
> - What that particular developer needs done
> - How hard a particular task looks
> - [in some cases] What someone is paying the developer(s) to do
>
> The last point is key: you can get true renames to happen
> faster by paying a developer to work on it. You might,
> understandably, complain that this would be prohibitively
> expensive. Exactly! Now you know why developers are so
> reluctant to pick it up :-). It's hard.
>
> Another approach, if you're up for it, would be for you (or
> someone) to put together an informal consortium of interested
> parties, to share the cost of finishing the true renames
> work. You'd each contribute a little bit to fund a
> developer. Naturally, there's some overhead in writing the
> contract, organizing the funding, etc -- that's something
> you'd have to take on. Or the developer could do the
> organizing, and just include that overhead in the bill.
>
> (I've sometimes considered doing that myself, but at the
> moment am booked with other stuff and would like to finish
> the sparse directories feature. Perhaps in the future I'll
> try this strategy.)
>
> We mostly ignored the voting information in the issue
> tracker, because it only included one dimension
> (desirability, but not difficulty), and it suffered from
> sample bias -- people who register an account and make
> comments in the issue tracker are not representative of all
> Subversion's users. Often, users behind corporate firewalls
> are not aware that there's a public issue tracker; sometimes
> they're even
> *prohibited* from making public comments on open source
> projects, believe it or not.
>
> I'm completely in favor of true renames getting finished, of
> course. I'm just trying to explain how work gets prioritized
> here, in the hope that this will enable you to figure out a
> way to help.
>
> Best,
> -Karl
>
> "Morel, Jacques" <Jacques.Morel@sabre-holdings.com> writes:
> > So my question is: how as the subversion development team, have you
> > facilitated the gathering of feedback from your user base and made
> > sure it wasn?t lost?
> >
> > As a user, how do I make sure my voice is heard at the
> right time? How
> > do I know when it is time to lobby again for a feature?
> >
> > Remember, we have daily life too and keeping track of
> subversion user
> > or dev mailing list may be too much to ask (it was for me
> for the past
> > 1+ year).
> >
> > I could not find anything on the web site about a feedback process.
> >
> > I believe that without a well defined process to define a release
> > scope, it is very hard to get a good idea of your user base needs.
> >
> >
> >
> > I suggest you spell out the process and ensure it is
> simple: some like
> > vote on the issue you care about or send an email explicitly to ask
> > feedback on content of next release or publish a wiki
> document and let
> > people comment on it?
> >
> > FYI at some point the voting system of collabnet issue tracking was
> > available and I invited several co-workers to vote for that
> issue. I
> > suppose it was turned off because you were not using it.
> Did you have
> > reason to reject its information?
> >
> >
> >
> > Again, even though I am passionate about this issue, I am also a
> > passionate supporter of subversion. So thanks for producing such a
> > great tool and investing your [personal] time into it.
> >
> > My life as a [open-source and closed-source] developer has
> been made
> > significantly less painful since we started using subversion (since
> > 1.0 in some projects).
> >
> >
> >
> > Jacques
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> 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 Thu Apr 12 23:47:21 2007