>>You know what this is? This is almost the SVN model! The only difference
>>is, that currently only ONE person can check something in (or in SVN
>>terms: "commit") and that poor person has to diff the whole sources and
>>manually insert changes!
That's pretty much what I've been saying... I haven’t been arguing that my
situation is different than the standard SVN model... in fact I haven't been
arguing at all...
To everyone who keeps saying... "You're doing it wrong because you don't
understand" I'd like to say... I've never said I wasn't "doing it wrong" I
just said that this is how it's being done and that this is partly due to
the structure of the product I've been using. As for me not "understanding"
I would argue that I think I understand it pretty well, there actually seems
to be some lack of understanding on the other side about how VSS works
(though Ingo has summed what I've been trying to explain up pretty well this
time around)... I also recognize that how VSS works is of next to no
interest to anyone here and subsequently don't have any problem with people
that don't understand the difference...they don't need to so don't bother.
I'm comfortable with how both systems work now and I understand the pros and
cons of both and how I would go about setting a system that would work in
both. I further recognize that SVN's approach does fit my work flow better
in general (by the way... that's pretty much why I'm here now).
I would restate once again.... I've continued participating in this
discussion primarily for the potential benefit of future possible converts
from VSS to SVN... I was hoping that by trying to explain in this discussion
the understanding that I have come to about the fundamental differences
between the products and approaches, that future VSS users who may read the
thread might find the transition that much easier.
No matter how much you might say "you need to stop thinking in the 'old way'
and see the light of the new religion" the fact is, first, that's simply not
possible, we all bring all our baggage with us and must find a way to
assimilate not replace. Second, I heard the same argument about object
oriented programming... and the fact is, if you tried to "through away"
everything you thought in structured programming, you're end understanding
of object orientation would be much more shallow... the fact is object
orientation is just a different form of encapsulation which is the
foundation of structured programming.... similar things can be said about
bring full understanding the VSS approach to version control with you as you
learn the differences in SVN.... I've seen a LOT of variation on the wheel
but I have yet to see a truly innovative wheel where I say "Wow! I've never
seen that before" I'd say the same is pretty much try about software... and
now as I survey more and more version control systems I'm seeing the same
thing here as well.
If you forget what you know to learn something new, then you only know one
thing... it's really hard to build a "broad knowledge base" that way and a
broad knowledge base can serve you very well over time.
Thank you all for your concern and persistence in trying to make me
understand.... You have helped me a lot. I frequently find that the best
way for me to clarify my own understanding of something is to be forced to
try to explain it to someone else. Subsequently, I REALLY DO THINK I'VE
GOT IT.
Regards,
Tom Malia
-----Original Message-----
From: Ingo Schmidt [mailto:ich@der-ingo.de]
Sent: Wednesday, March 21, 2007 4:05 PM
To: users@subversion.tigris.org
Subject: Re[2]: GUI Diff on Repository HEAD and "a" directory?
Hi Tom!
> I don’t really want to keep the two systems going long term.
As others have suggested, set a date and do the switch. Anything else
is going to be a pain. We can see it, you describe it to us ;-)
We have just done it at my company. Going from VSS to SVN. We set a
date and changed. Couldn't have gone better.
They way I did it was this:
Behind the scenes I was optimizing an automated conversion until it
was really fully automatic. So before people went home, everyone
checked their stuff in, I started the conversion over night and the
next day VSS was no more.
> just to give you an idea of what I’m dealing with here probably
> don’t even now how to open the command prompt window anymore.
I do hate answer like this myself, but sorry, here it comes:
Teach them the proper way! Really, they will notice how much easier it
is! What you describe is just calling out for using something like
SVN...
And with TortoiseSVN it couldn't be easier.
If I do understand you correctly, source code gets passed around and
one day it comes back to you or your company, right? So either you or
some guy at ur place diffs that against the VSS database and checks in
the changes. Right so far?
If you want to keep it like that, well, just copy the stuff you get
back from them into your working copy and try to commit it. Or if you
need to check it before committing, run a diff. It is now possible and
should be really easy.
If there are no conflicting changes, you don't even have to merge by
hand. SVN will do it for you.
But I would go the other way:
Teach people how to use SVN! If it is like you say, it must take ages
to diff all those changes someone might send back! Either give the
other companies write access to your repository or if that is
inacceptable, have them send in patch files! TSVN can create them very
easily. No command line stuff needed.
Or you could just give other companies write access to only the
branches folder and they work in there. When they are done, they tell
you and you try to merge it back in. Again, diffing is then more than
easy. It is all in the repository.
I am going to repeat myself, but looking at what you describe, if you
do have the time, write up clear instructions and tell everyone who is
to work with your sources to stick to these rules. After lots of
complaining (I know they will ;-)) they will soon realize how very
much easier the whole thing is!
Trust me, I went through it in my company. How reluctant were they and
now that it is done they start to see how much nicer it is!
> As you all have been telling me, it’s a different world… I can
> accept that that is the fact, but I’m the type that needs to work
> through those differences in detail and I need to understand where,
> when and WHY the particular difference exist.
Okay, let me try to sum it up:
- People do get "working copies" now with VSS (get latest version)
- They modify their "working copy"
- They send it back to you
- You check out the files you need and diff them
- You manually insert the changes they made
You know what this is? This is almost the SVN model! The only
difference is, that currently only ONE person can check something in
(or in SVN terms: "commit") and that poor person has to diff the whole
sources and manually insert changes!
With SVN the above would look like this:
- People check out their working copies
- People modify their working copy
- People try to commit it. Changes will be auto merged, unless there
are conflicts
If you do need to check changes before they are actually going to be
committed, have people work in branches and then merges those branches
to trunk.
Really, what you are doing now, is already halfway there, but VSS is
getting in your way with it's lock-modify-unlock model.
Was this helpful? If not, ask again :-)
Cheers, Ingo =;->
---------------------------------------------------------------------
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 Wed Mar 21 23:09:36 2007