RE: GUI Diff on Repository HEAD and "a" directory?

>>change the way you work

"Change the way you work" isn't always an option. at least not over night.
I recognize some value switch from VSS to SVN but my developers don't yet
see the need. If I stand a snowballs chance of weaning them off VSS I have
to make the transition VERY easy. Which means for some period of time, I
plan to slowly migrate projects that are actively being developed into SVN
while my programmers continue using VSS.

>>This might have been an issue when consultant's would have needed a VSS
license and even then probably did not have access to your repository.
>>Anyone can get a copy of Subversion and it would be easy technically
(maybe not politically or other really good reasons) to get these people
>>access to the repository. I would consider working with consultants the
same way open source projects work. Give them read access to a >>repository
and ask them to submit patches. This works really well.

I guess I'll have to read up more on "patches" does the programmer have to
"Do anything" with Subversion to be able to submit their changes as patches?
If so, then again, this is not really going to be work since I probably wont
be able to dictate that they use subversion.. Or rather, if I do dictate
this then they are going to charge me for probably a lot of billable hours
for them to "monkey around" with something they are not familiar with. It
doesn't matter that it may in fact be easy, they'll still say, "if you want
me to do the work and you require me to use this tool I don't know, then I'm
going to bill you $X.XX amount"

  _____

From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Sunday, March 18, 2007 3:19 PM
To: Tom Malia
Cc: Subversion Users mailing list
Subject: Re: GUI Diff on Repository HEAD and "a" directory?

On 3/18/07, Tom Malia <tommalia@ttdsinc.com> wrote:

[Tom Malia] It's a team development is the issue. at any given time, I've
got 2 or three programmers (non-in the same geographic area) working on the
code for a single EXE. Some working on some features and bugs and others
working on other features and bugs. In VSS, you don't have "merge"
functionality so frequently one person checks the project out while other
"get latest version" (the equivalent of export) and every works on the stuff
they need to work in. Then, before you "check in" if you were one of the
ones that just did an export, you Diff the entire project in your working
folder against the current contents of the repo version of the project then
go through and manually perform a merge and then check your stuff into the
repo. I know this isn't the way things are "suppose to be done" but it's
how things are done and it's really fairly functional for us for right now.

But that was my point. You were doing this because of VSS. Subversion does
not have these problems or limitations, so change the way you work so that
you are letting Subversion do this work for you.
 

Another occasional scenario occurs when we need to ship a project's source
code off to an outside consultant to deal with particular problem or
something and that outsourcer doesn't have SVN, so we package the
development directory up, send it off and when it comes back with the
desired correction, it also comes back without the .SVN folder. again, not
ideal but these are the kind of things that happen.

This might have been an issue when consultant's would have needed a VSS
license and even then probably did not have access to your repository.
Anyone can get a copy of Subversion and it would be easy technically (maybe
not politically or other really good reasons) to get these people access to
the repository. I would consider working with consultants the same way open
source projects work. Give them read access to a repository and ask them to
submit patches. This works really well.
 

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/