On 3/18/07, Tom Malia <tommalia@ttdsinc.com> wrote:
>
> >>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.
>
yes just "changing your workflow" is very difficult, but thats basically
what you have to do when switching from VSS to SVN. its very difficult to
do a smooth merge, slowly using svn more and more - its just not
changing the way you work will be much easier than trying to make svn act
like 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/
>
Received on Mon Mar 19 01:33:52 2007