You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Eric <sp...@scoot.netis.com> on 2006/11/08 06:10:15 UTC
Concurrent versioning = spawn of the devil?
Can someone point me to some information on the web that I can use to
convince my co-developer that concurrent versioning, with unlocked files,
isn't the absolute evil that he claims it is?
I've been arguing with him about it for half the evening and I'm just about
out of ideas...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Matt Sickler <cr...@gmail.com>.
On 11/8/06, Robert Graf-Waczenski <rg...@lsoft.com> wrote:
> The main reason in my eyes is: If you have good merging tools, CMM is
> actually fine and there are no problems whatsoever with it. The use case
> simply is: "I want my changes to not silently overwrite changes that
> others have made to the same file". Learning that SVN waits to inform you
> about a new version in the repository as late as when you try to commit
> sounds "evil" on first glance because one is tempted to think that your
> changes are lost and you are forced to redo them. No. Wrong. Instead,
> you still have your local changes and you are asked to merge the changes
> from the repository with your own changes, yielding a merged version of
> the file. So, your changes are not lost. VSS users typically *hate* merging
> simply because the default merging window of the VSS explorer is such
> an awful tool to work with: No syntax coloring, no obvious pointers on
> how to apply which of the two changes and what the result will look like.
> (It *does* display all the information you need, but I frequently have
> a hard time performing a merge operation and it often leaves me unsure
> if the result is ok or not.)
Dont forget you can always grab the latest version from the server
with `svn update`.
You dont have to wait for anything to know if there are changes in the repo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Mark <ma...@mitsein.net>.
http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html#svn.basic.vsn-models.copy-merge
On 11/7/06, Eric <sp...@scoot.netis.com> wrote:
>
> Can someone point me to some information on the web that I can use to
> convince my co-developer that concurrent versioning, with unlocked files,
> isn't the absolute evil that he claims it is?
>
> I've been arguing with him about it for half the evening and I'm just about
> out of ideas...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Tim Hill <dr...@comcast.net>.
Why don't you invite him to post his issues here? I'm sure he will
get some thoughtful responses.
--Tim
On Nov 9, 2006, at 12:36 PM, Erik Huelsmann wrote:
> On 11/8/06, Eric <sp...@scoot.netis.com> wrote:
>>
>> Can someone point me to some information on the web that I can use to
>> convince my co-developer that concurrent versioning, with unlocked
>> files,
>> isn't the absolute evil that he claims it is?
>>
>> I've been arguing with him about it for half the evening and I'm
>> just about
>> out of ideas...
>
> I couldn't help noticing a flood of mails all relating to this topic
> (originating from you :-)
>
> Have you ever considered doing a pilot with Subversion for one
> project, to make sure your partner gets the fuzzy Subversion feeling
> from his own experience (or he really hates it afterwards but then
> it'll be easier to move off Subversion since you only have 1 project
> in it...)
>
> HTH,
>
> Erik.
>
> ---------------------------------------------------------------------
> 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
Re: Concurrent versioning = spawn of the devil?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/9/06, Eric Poole <er...@rkt-tech.com> wrote:
> At 03:36 PM 11/9/2006, Erik Huelsmann wrote:
>
> <EH>>>>>Have you ever considered doing a pilot with Subversion for one
> project,<<<<<
>
> Good afternoon, Erik.
>
> Sorry about the flood...
Don't get me wrong: the list is here exactly to help you answer any
and all of the questions you have asked so far, but it looked to me
like your partner might need hard (self experienced) data about how to
work with Subversion without the bad tastes from VSS.
> That's exactly what I'm trying to do. So far not a lot of progress, but
> we'll see.
But what I mean is not to pilot with all your company assets (which is
what your mails sound like now), but with a small - maybe even totally
unimportant - project where it's not a big problem that resources may
be 'in danger'.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Eric Poole <er...@rkt-tech.com>.
At 03:36 PM 11/9/2006, Erik Huelsmann wrote:
<EH>>>>>Have you ever considered doing a pilot with Subversion for one
project,<<<<<
Good afternoon, Erik.
Sorry about the flood...
That's exactly what I'm trying to do. So far not a lot of progress, but
we'll see.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 11/8/06, Eric <sp...@scoot.netis.com> wrote:
>
> Can someone point me to some information on the web that I can use to
> convince my co-developer that concurrent versioning, with unlocked files,
> isn't the absolute evil that he claims it is?
>
> I've been arguing with him about it for half the evening and I'm just about
> out of ideas...
I couldn't help noticing a flood of mails all relating to this topic
(originating from you :-)
Have you ever considered doing a pilot with Subversion for one
project, to make sure your partner gets the fuzzy Subversion feeling
from his own experience (or he really hates it afterwards but then
it'll be easier to move off Subversion since you only have 1 project
in it...)
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Concurrent versioning = spawn of the devil?
Posted by Eric <sp...@scoot.netis.com>.
At 07:29 AM 11/8/2006, Robert Graf-Waczenski wrote:
<RGW>>>>>I don't remember from your posts that your project uses Java, so
you may have to look for something else.<<<<<
Good morning, Robert.
This particular project is C++, but we also do work in Java and Ada and
Visual Basic, and whatever we pick for a version control system needs to be
suitable for all of those.
<RGW>>>>>But, to repeat myself: The VSS merge tool sucks big time, your
friend is right in saying that one should not expose clients to an
environment that frequently requires code merges *with this tool*<<<<<
Right, and that has led him to the inescapable conclusion that merging is
evil and one should never do it.
He doesn't want to expose clients to the dangers of merging but he's
perfectly happy to expose clients to VSS ... go figure ... :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning (access methods, passwords vs keys)
Posted by Thomas Harold <tg...@tgharold.com>.
Eric wrote:
> I will have to revisit TortoiseSVN and see if I can get that to work...
> the problem there is that it doesn't remember my login name and password
> and so I have to enter my password just about every time I change
> directories, gets REALLY old after about the third or fourth time. For
> now we are trying to do this using login and password rather than SSH
> public/private keys, to ease client use, but I guess I'll have to
> revisit that.
From my experience, PuTTY keys with Pageant (loaded at startup and
prompting the user for their passphrase as soon as they login) combined
with svn+ssh is definitely the easiest of the methods. No password
prompts after the initial login and everything "just works" (and is very
secure).
Of course, it requires that you run a SSH daemon on the server (tricky
in Windows, but I hear cygwin works well). It also works best in
Unix/Linux where you can assign users to groups and assign those groups
proper permissions for the repository folders.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Ruslan Sivak <rs...@istandfor.com>.
I'm not sure about your username and password, but tortoise remembers my
username and pw just fine. Of course we're using apache/svnserve for
the backend, not ssh, but I don't see why there should be a difference.
Russ
Eric wrote:
> At 01:38 AM 11/8/2006, Kenneth Porter wrote:
>
> <KP>>>>>Tell us what arguments he uses. Odds are that his opposition
> stems from a misunderstanding.<<<<<
>
> He simply says that concurrent versioning is too dangerous, merging is
> too difficult and too much subject to error. He says that we are
> exposing our clients to too much risk if we subject their code to that
> kind of an environment.
>
> It's not helping that we can't see when a file is locked until we try
> to check it in. I know ... the answer is "don't lock the damn thing"
> ... but that falls on deaf ears, I get "I'm not checking ANYTHING out
> unless I can lock it and keep all you jabronis out of it!".
>
> The issues we're having with SmartSVN, mostly the one about SmartSVN
> hanging up on us when trying to check in a locked file, are really
> making him dig in his heels.
>
> I will have to revisit TortoiseSVN and see if I can get that to
> work... the problem there is that it doesn't remember my login name
> and password and so I have to enter my password just about every time
> I change directories, gets REALLY old after about the third or fourth
> time. For now we are trying to do this using login and password
> rather than SSH public/private keys, to ease client use, but I guess
> I'll have to revisit that.
>
> Are there any other GUIs besided SmartSVN and Tortoise? I wasn't able
> to find any...
>
>
> ---------------------------------------------------------------------
> 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
RE: Concurrent versioning = spawn of the devil?
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
> <KP>>>>>Tell us what arguments he uses. Odds are that his
> opposition stems
> from a misunderstanding.<<<<<
>
> He simply says that concurrent versioning is too dangerous,
> merging is too
> difficult and too much subject to error. He says that we are
> exposing our
> clients to too much risk if we subject their code to that kind of an
> environment.
Based on a tool as unusable as VSS's merge dialog, I can very
well understand such a statement. I have been working with this
bastard for seven years now and still have bad feelings each time
i have to use it.
So you should spend more time finding an intuitive merge tool
that comes with syntax coloring etc. I'm very fond of the Java
source code merge tool that comes with IntelliJ IDEA and the
SVN integration that is available there, but I don't remember
from your posts that your project uses Java, so you may have to
look for something else.
But, to repeat myself: The VSS merge tool sucks big time, your
friend is right in saying that one should not expose clients to
an environment that frequently requires code merges *with this tool*
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Concurrent versioning = spawn of the devil?
Posted by Thomas Hemmer <th...@go-engineering.de>.
Eric,
let me spend my 2 cents on that issue ...
> He simply says that concurrent versioning is too dangerous,
> merging is too difficult and too much subject to error. He
> says that we are exposing our clients to too much risk if we
> subject their code to that kind of an environment.
Maybe he isn't such wrong with his opinion.
On the other hand, there are thousands of developer teams around the
globe who _practise_ merging in their everyday business (I've even been
told by one of those folks that they are _forced_ to do so because of
several reasons) ;-)
Should they all produce weak code???
By the way, I personally prefer the locking method since I am working
with a rather small team (5 dev's) sitting within the same building and
our projects are fairly small, too (a few dozens of source files which
together weigh maybe some 10000 LOC typically).
I have no experience in working on widely distributed projects with
dozens of dev's, but I very much suppose the locking approach might
simply not be applicable in such a scenario.
> It's not helping that we can't see when a file is locked
> until we try to check it in. I know ... the answer is "don't ...
Simply tell him to categorically update his working copy and lock the
file he is going to alter _before_ making any changes to his WC.
Either there already _is_ a lock set on that very file (or set of
files); then he is told so (svn even provides him with the reason why
the file is locked!) and should delay his work until the lock has been
released again.
Or there has'nt been any; in this case he can immediately start his work
while being sure noone else won't interfere with his efforts.
> Are there any other GUIs besided SmartSVN and Tortoise? I wasn't able
to find any...
You don't need to ;-)
IMHO it would be really hard to design a tool that outbeats TSVN ...
Hope this helps,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Eric <sp...@scoot.netis.com>.
At 01:38 AM 11/8/2006, Kenneth Porter wrote:
<KP>>>>>Tell us what arguments he uses. Odds are that his opposition stems
from a misunderstanding.<<<<<
He simply says that concurrent versioning is too dangerous, merging is too
difficult and too much subject to error. He says that we are exposing our
clients to too much risk if we subject their code to that kind of an
environment.
It's not helping that we can't see when a file is locked until we try to
check it in. I know ... the answer is "don't lock the damn thing" ... but
that falls on deaf ears, I get "I'm not checking ANYTHING out unless I can
lock it and keep all you jabronis out of it!".
The issues we're having with SmartSVN, mostly the one about SmartSVN
hanging up on us when trying to check in a locked file, are really making
him dig in his heels.
I will have to revisit TortoiseSVN and see if I can get that to work... the
problem there is that it doesn't remember my login name and password and so
I have to enter my password just about every time I change directories,
gets REALLY old after about the third or fourth time. For now we are
trying to do this using login and password rather than SSH public/private
keys, to ease client use, but I guess I'll have to revisit that.
Are there any other GUIs besided SmartSVN and Tortoise? I wasn't able to
find any...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Wednesday, November 08, 2006 1:10 AM -0500 Eric
<sp...@scoot.netis.com> wrote:
> Can someone point me to some information on the web that I can use to
> convince my co-developer that concurrent versioning, with unlocked files,
> isn't the absolute evil that he claims it is?
>
> I've been arguing with him about it for half the evening and I'm just
> about out of ideas...
Tell us what arguments he uses. Odds are that his opposition stems from a
misunderstanding.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
Andy Peters wrote:
> On Nov 8, 2006, at 1:58 AM, Robert Graf-Waczenski wrote:
>
>
>> Subversion, OTOH, by default uses the "Copy-Modify-Merge" pattern,
>> which
>> has some downsides on first glance if you are used to the VSS
>> patterns.
>> With the Subversion pattern, the user is not notified about changes by
>> others until the user *commits* his own changes.
>>
>
> To be completely clear: the user is not notified about changes
> committed by others until after the user attempts to commit his own
> changes. If any changes were made, there's a conflict and the user
> has to resolve it before he's allowed to commit his changes.
I'm not sure that's completely clear: there may be changes in the repos
that require an update, but doing an update may successfully merge them
into the user's code. Usually saying there's a "conflict" means that
the automatic merge was unsuccessful.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Talden <ta...@gmail.com>.
On Tue, 2006-11-14 at 13:33 -0800, Tim Hill wrote:
> > I guess it would help to understand the workflow better. You
> > mentioned talking over the phone and people who the document but do
> > not have access to svn or the repository. What is the intended usage
> > here? There is probably some form of tagging that will give you what
> > you want.
On 15/11/06, Les Mikesell <le...@gmail.com> wrote:
> I was thinking of the type of document that might be passed around
> and reviewed by a committee of people who don't have direct access
> to the repository and may or may not do any actual revisions to the
> text (returning it to someone to commit) but always need to know if
> the copy they are viewing is current.
CVS revisions don't work well here either.
The revision number is a bad measure of activity.
Consider what branching and merging do to revisions. Why aren't
branch commits accounted for in the main revision? Are merges really
changes or just absorbing a set of changes in a branch - shouldn't the
HEAD revision jump by the number of merged changes?.
Clearly the issue of the scale and depth of changes is also a very
important variable in measuring activity. The size and number of
diffs don't even give a reliable measure here. Is indenting a whole
file significant?
And by itself the revision number doesn't give any indication of how
current a file is, merely that it's more or less recent than a file
with a different number.
Best would be for a release mechanism to supply an electronically
signed release document which encloses electronic signatures for each
of the released documents. This way the release and its contents can
be authenticated.
I approach Subversion from an SCM perspective so I'm overjoyed at
subversions avoidance of two key bugbears (non-atomic commits breaking
concurrent updates and committers failing to observe changes prior to
commits).
Maybe Subversion is a square peg for a round hole... Or maybe the hole
being round isn't a real requirement.
I hope you find a solution that is suitable, but I don't think an SCM
is going to be the silver bullet by itself for the situation you're
describing.
NB: In case it hasn't been corrected - You don't have to get an entire
source-tree, you can pull down a single folder non-recursively. You
cannot practically get a single file though.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Tim Hill <dr...@comcast.net>.
I guessed as much ... the classic email discussion/edit, with all the
attendant problems. :(
I don't really think this is solvable by Subversion or any other scc
system unless everyone has access to it. In a pure serial workflow
the problem is trivial; the current version is owned by whoever has
it. Of course this never works ... its serialized so too slow,
someone gets the document and then goes on vacation leaving it in
their inbox etc etc. That's really what the various WebDAVish
document repository systems try to solve (though not very well, imho).
fwiw, if you aren't going to roll out svn for everyone, then frankly
its not going to help with the issue regardless of rev# issues.
--Tim
On Nov 14, 2006, at 2:06 PM, Les Mikesell wrote:
> On Tue, 2006-11-14 at 13:33 -0800, Tim Hill wrote:
>> I guess it would help to understand the workflow better. You
>> mentioned talking over the phone and people who the document but do
>> not have access to svn or the repository. What is the intended usage
>> here? There is probably some form of tagging that will give you what
>> you want.
>
> I was thinking of the type of document that might be passed around
> and reviewed by a committee of people who don't have direct access
> to the repository and may or may not do any actual revisions to the
> text (returning it to someone to commit) but always need to know if
> the copy they are viewing is current.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
> ---------------------------------------------------------------------
> 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
Re: Subversion vs CVS for document files
Posted by Jeremy Pereira <je...@jeremyp.net>.
On 14 Nov 2006, at 22:06, Les Mikesell wrote:
> On Tue, 2006-11-14 at 13:33 -0800, Tim Hill wrote:
>> I guess it would help to understand the workflow better. You
>> mentioned talking over the phone and people who the document but do
>> not have access to svn or the repository. What is the intended usage
>> here? There is probably some form of tagging that will give you what
>> you want.
>
> I was thinking of the type of document that might be passed around
> and reviewed by a committee of people who don't have direct access
> to the repository and may or may not do any actual revisions to the
> text (returning it to someone to commit) but always need to know if
> the copy they are viewing is current.
I'd be interested to know how a CVS style revision number would be
any better in this instance. You would still need access to the CVS
repository or working copy to determine the rev number.
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
> ---------------------------------------------------------------------
> 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
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-14 at 13:33 -0800, Tim Hill wrote:
> I guess it would help to understand the workflow better. You
> mentioned talking over the phone and people who the document but do
> not have access to svn or the repository. What is the intended usage
> here? There is probably some form of tagging that will give you what
> you want.
I was thinking of the type of document that might be passed around
and reviewed by a committee of people who don't have direct access
to the repository and may or may not do any actual revisions to the
text (returning it to someone to commit) but always need to know if
the copy they are viewing is current.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Tim Hill <dr...@comcast.net>.
I guess it would help to understand the workflow better. You
mentioned talking over the phone and people who the document but do
not have access to svn or the repository. What is the intended usage
here? There is probably some form of tagging that will give you what
you want.
--Tim
On Nov 14, 2006, at 12:44 PM, Les Mikesell wrote:
> On Tue, 2006-11-14 at 15:29 -0500, Duncan Murdoch wrote:
>>>
>>> How do you describe this document, say over the phone? I've got
>>> Revision: 528, someone else got 595, neither of us currently have
>>> access to the log file. Are they the same document or not?
>>
>> How did you determine that you've got rev 595? You looked in the
>> wrong
>> place in svn info. You don't need the log for that.
>
> That's what svn update told me when I got it. What's the right place
> to look for the right info, and how would you describe it so everyone
> is sure if they have the same thing when no one involved has svn
> access at the time? Unlike source code, documents tend to have their
> own lives outside of the repository. What's the shortest way to
> describe the last change if you don't copy it to a tag?
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
> ---------------------------------------------------------------------
> 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
Re: Subversion vs CVS for document files
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 14, 2006, at 15:35, Les Mikesell wrote:
>> You don't need remote access to run svn info. If you don't even have
>> local svn access to a working copy, then I guess you're out of luck,
>> unless you had the foresight to use svn:keywords in the file.
>
> Well, that's the point. svn:keywords might work in the unlikely
> event that this is a plain text document and someone thought to
> add them. [snip]
svn:keywords can work in binary documents too (e.g. Word documents or
what have you). Just be sure to use the fixed-width keyword syntax:
http://svn.haxx.se/users/archive-2005-07/0819.shtml
However, keywords wouldn't work in compressed documents, like
OpenOffice.org documents. :-/
If you don't want keywords appearing in your files, perhaps because
it looks ugly, then that's your decision, but that decision applies
just as much to text files as it does to binary files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-14 at 16:08 -0500, Duncan Murdoch wrote:
> svn update -rCOMMITTED file
>
> but that's a weird thing to do. Why would you want to update a file
> just to figure out its revision number???)
I agree that is a weird thing to have to do to find out the information
you are likely to want as opposed to some unrelated thing. You'll want
to update to get the current version regardless, but you also want to
know how to describe it outside of the context of the repository.
> What's the right place
> > to look for the right info, and how would you describe it so everyone
> > is sure if they have the same thing when no one involved has svn
> > access at the time?
>
> You don't need remote access to run svn info. If you don't even have
> local svn access to a working copy, then I guess you're out of luck,
> unless you had the foresight to use svn:keywords in the file.
Well, that's the point. svn:keywords might work in the unlikely
event that this is a plain text document and someone thought to
add them. Otherwise you need a short description of the last
change so two people with copies outside of the repository know
if they have the same thing.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 11/14/2006 3:44 PM, Les Mikesell wrote:
> On Tue, 2006-11-14 at 15:29 -0500, Duncan Murdoch wrote:
>> >
>> > How do you describe this document, say over the phone? I've got
>> > Revision: 528, someone else got 595, neither of us currently have
>> > access to the log file. Are they the same document or not?
>>
>> How did you determine that you've got rev 595? You looked in the wrong
>> place in svn info. You don't need the log for that.
>
> That's what svn update told me when I got it.
Then I guess you misunderstood the message from svn. It told you that
you have the version of the file that's current in that repository
revision. If you want to know the version of the file as of its last
change, you should have used svn info (or if you insist on using svn
update, you could have updated it using
svn update -rBASE file
or maybe
svn update -rCOMMITTED file
but that's a weird thing to do. Why would you want to update a file
just to figure out its revision number???)
What's the right place
> to look for the right info, and how would you describe it so everyone
> is sure if they have the same thing when no one involved has svn
> access at the time?
You don't need remote access to run svn info. If you don't even have
local svn access to a working copy, then I guess you're out of luck,
unless you had the foresight to use svn:keywords in the file. But how
would you determine any form of version number without even having local
svn access???
> Unlike source code, documents tend to have their
> own lives outside of the repository. What's the shortest way to
> describe the last change if you don't copy it to a tag?
"-rCOMMITTED"
or a paste from the svn info output.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-14 at 15:29 -0500, Duncan Murdoch wrote:
> >
> > How do you describe this document, say over the phone? I've got
> > Revision: 528, someone else got 595, neither of us currently have
> > access to the log file. Are they the same document or not?
>
> How did you determine that you've got rev 595? You looked in the wrong
> place in svn info. You don't need the log for that.
That's what svn update told me when I got it. What's the right place
to look for the right info, and how would you describe it so everyone
is sure if they have the same thing when no one involved has svn
access at the time? Unlike source code, documents tend to have their
own lives outside of the repository. What's the shortest way to
describe the last change if you don't copy it to a tag?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 11/14/2006 3:18 PM, Les Mikesell wrote:
> On Tue, 2006-11-14 at 12:46 -0500, Duncan Murdoch wrote:
>> >
>> >> >> Actually I think the single rev# is one of the best features of SVN.
>> >> >> Having used "per-file" rev# systems, which deteriorate into chaos, I
>> >> >> far prefer the Subversion approach. Plus the fact that, in effect, a
>> >> >> rev# becomes a changelist.
>> >> >
>> >> > It makes sense for a 'project'. It doesn't make much sense
>> >> > for a collection of mostly unrelated files and it is cumbersome
>> >> > to put each in its own repository.
>> >>
>> >> Why not? If you just think of revision numbers as tags, they are just
>> >> as meaningful whether they increase sequentially or by bigger jumps.
>> >
>> > How is it meaningful - or useful - for a revision number to change
>> > when no related content changed? If you have a later version than
>> > mine, how do I know if it is different or not?
>>
>> You look at the log for that file. If you want to know which version
>> you've got, you read "Last Changed Rev: 528" from svn info, rather than
>> "Revision: 595". That's the number the svn:keywords will give you if
>> you want to insert it into the text.
>>
>> This is only a problem if you're desperately searching for problems.
>
> How do you describe this document, say over the phone? I've got
> Revision: 528, someone else got 595, neither of us currently have
> access to the log file. Are they the same document or not?
How did you determine that you've got rev 595? You looked in the wrong
place in svn info. You don't need the log for that.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-14 at 12:46 -0500, Duncan Murdoch wrote:
> >
> >> >> Actually I think the single rev# is one of the best features of SVN.
> >> >> Having used "per-file" rev# systems, which deteriorate into chaos, I
> >> >> far prefer the Subversion approach. Plus the fact that, in effect, a
> >> >> rev# becomes a changelist.
> >> >
> >> > It makes sense for a 'project'. It doesn't make much sense
> >> > for a collection of mostly unrelated files and it is cumbersome
> >> > to put each in its own repository.
> >>
> >> Why not? If you just think of revision numbers as tags, they are just
> >> as meaningful whether they increase sequentially or by bigger jumps.
> >
> > How is it meaningful - or useful - for a revision number to change
> > when no related content changed? If you have a later version than
> > mine, how do I know if it is different or not?
>
> You look at the log for that file. If you want to know which version
> you've got, you read "Last Changed Rev: 528" from svn info, rather than
> "Revision: 595". That's the number the svn:keywords will give you if
> you want to insert it into the text.
>
> This is only a problem if you're desperately searching for problems.
How do you describe this document, say over the phone? I've got
Revision: 528, someone else got 595, neither of us currently have
access to the log file. Are they the same document or not?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Tim Hill <dr...@comcast.net>.
Yes, I agree with Ted ... kill VSS, then let svn fight it out with
Perforce or ClearCase (and wait until you see what they want per copy!).
--Tim
On Nov 15, 2006, at 11:57 AM, Ted Dennison wrote:
> Tim Hill wrote:
>> VSS is not an industrial-strength product. Subversion is. Period.
>> And, yes, I've used both extensively.
> It might be worth backing off of Subversion, and just attacking
> VSS. There are some good alternatives to Subversion out there, but
> VSS is not one of them. An "anything but VSS" attitude may pay you
> better dividends than trying to defend SVN. Perhaps after VSS is
> tossed and alternatives are being discusssed, SVN can be brought
> up. But even if you end up having to go with something like
> Perforce instead, you will still be *waaaaaaay* ahead for not
> having to use VSS. That alone would be an accomplishment you can be
> happy with.
>
> As for ammo, a good (alternative neutral) place to get started
> would be http://www.codinghorror.com/blog/archives/000660.html
>
> --
> T.E.D. Work - mailto:dennison@ssd.fsi.com
> Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
> Homepage - http://www.telepath.com/~dennison/Ted/TED.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Ted Dennison <de...@ssd.fsi.com>.
Tim Hill wrote:
> VSS is not an industrial-strength product. Subversion is. Period. And,
> yes, I've used both extensively.
It might be worth backing off of Subversion, and just attacking VSS.
There are some good alternatives to Subversion out there, but VSS is not
one of them. An "anything but VSS" attitude may pay you better dividends
than trying to defend SVN. Perhaps after VSS is tossed and alternatives
are being discusssed, SVN can be brought up. But even if you end up
having to go with something like Perforce instead, you will still be
*waaaaaaay* ahead for not having to use VSS. That alone would be an
accomplishment you can be happy with.
As for ammo, a good (alternative neutral) place to get started would be
http://www.codinghorror.com/blog/archives/000660.html
--
T.E.D. Work - mailto:dennison@ssd.fsi.com
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/~dennison/Ted/TED.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Tim Hill <dr...@comcast.net>.
Well, maybe point him to any number of web discussions about how VSS
regularly loses *everything* that it has stored. Does he want minor
workflow issues around rev numbers, or total data loss?
VSS is not an industrial-strength product. Subversion is. Period.
And, yes, I've used both extensively.
--Tim
On Nov 15, 2006, at 9:06 AM, Eric wrote:
>
> The one person who is most adamantly opposed to SVN and is so
> adamantly pushing VSS is a partner in the business and so there is
> no one above him who can do any of that.
>
> He is a "my way or the highway" type whose mind typically cannot be
> changed.
Re: Subversion vs CVS for document files
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 16, 2006, at 05:12, Jeremy Pereira wrote:
> From reading some of those 1.5 million articles it seems that
> unplugging your computer's network cable while in the middle of
> committing changes should be enough to corrupt your VSS
> repository. It would be unethical to do that to deliberately
> discredit the product, of course :-)
Not at all -- it seems only responsible to stress-test the product
before deploying it, putting it through various worst-case scenarios
to see how it responds.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: VSS to SVN (Was: RE: Subversion vs CVS for document files)
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Friday, November 17, 2006 9:08 AM +0100 Robert Graf-Waczenski
<rg...@lsoft.com> wrote:
> Some examples where vss2svn decided to orphanize a file were explainable
> from the history in VSS, but some orphaned files appeared to have a
> rather trivial history (i.e. no sharing/branching/whatnot but only plain
> changes accumulated over time).
The converter extracts the history of each file in VSS into an XML file
that is then used to guide the conversion. The XML is a text translation of
the binary metadata in the VSS DB. You can look at the temporary files
generated during the conversion to identify which VSS "physical" file
represents your actual file. Then run "ssphys info" against that physical
file to dump the XML description of its history. From this you should be
able to determine what anomalies made it hard for the conversion script to
figure out what to do.
When I was trying to figure out all the problems in my VSS DB, I used the
following script to dump all the physical files in the DB. I could then
grep through them to trace the winding paths each file took.
#!/bin/sh
CONVERTROOT=/mnt/New/root
CONVERTVSS=${CONVERTROOT}/VSS-20060921/data
CONVERTXML=${CONVERTROOT}/info
rm -Rf ${CONVERTXML}
cd ${CONVERTVSS}
for i in [a-z] ; do
cd ${CONVERTVSS}/$i
rm -Rf ${CONVERTXML}/$i
mkdir -p ${CONVERTXML}/$i
for j in *aa ; do
echo $j
ssphys info $j > ${CONVERTXML}/$i/$j.xml
done
done
As you can see, I, too, did my conversion on a new disk to get the needed
space for multiple attempts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
VSS to SVN (Was: RE: Subversion vs CVS for document files)
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
Spawning a new thread since this part of the discussion not exactly
fits into the old thread.
> (Even with all that, I still couldn't get vss2svn working... so we just
> left VSS+SOS in place for historical purposes and loaded the current
> revision of everything into SVN.)
We tried to use vss2svn to migrate our VSS db to SVN. It worked quite well
but some files were orphaned due to reasons that were not clearly
explainable
from looking at the history. vss2svn uses "orphans" to store files that
have undergone freaky events during their history which can not be
interpreted faithfully after the fact. If you have fiddled a lot with
sharing,
branching and pinning in VSS for a certain file, then orphaning it is
some sort of a safe resort to at least have the file in svn after the
migration. Some examples where vss2svn decided to orphanize a file were
explainable from the history in VSS, but some orphaned files appeared to
have
a rather trivial history (i.e. no sharing/branching/whatnot but only plain
changes accumulated over time).
This behavior left us with some sort of uncertain feeling in the neck
about how well the history would be represented in SVN after the migration,
so we plan to do *exactly* what you did.
Since the migration heavily depends on features of svndumpfilter and
svnadmin load, the problems we observed can not necessarily only be
blamed on vss2svn alone.
Oh, and BTW, don't ask about any log files that were written during
the migration. I had to delete the stuff from my 40GB disk which ran
full after the migration attempt. Now i have roughly 20GB free again ;-)
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Thomas Harold <tg...@tgharold.com>.
Robert Graf-Waczenski wrote:
> Ah, VSS bashing! Can't resist to join...
>
> VSS, by design, depends heavily on well-synchronized system clocks of all
> client computers performing checkins. In the worst case, your VSS database
> is trashed completely simply because one computer checks in a change while
> his system clock is on a time *before the VSS project was created*. The main
> lesson to learn from this is: You can simply not trust the VSS history
> because all timestamps reflected in the history stem from the system clock
> that the client computer had when the checkin was executed.
> The MSDN says to this: "Make sure that you synchronize the dates and system
> clocks for all Visual SourceSafe client computers".
Interesting, I hadn't paid attention to that.
However, we had good luck using VSS for 6 years for 5 developers prior
to switching over to SVN.
Our secret? We only accessed VSS via SourceOffSite, a 3rd party tool
suited for WAN access which ran on the same server as the VSS
repository. Basically we did an end-run around the common cause of VSS
corruption issues.
(Even with all that, I still couldn't get vss2svn working... so we just
left VSS+SOS in place for historical purposes and loaded the current
revision of everything into SVN.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Thu, 2006-11-16 at 14:30 +0000, Nikki Locke wrote:
> I uses SourceOffSite extensively, and found serious problems with it. Any
> attempt to check out a large directory tree would result in the checkout
> hanging part way through. Sometimes this would hang up the SourceOffSite
> server so it accepted no further connections. At other times it was
> possible to recover without rebooting the server, but the only way to get a
> large tree was to get one or two directories at a time.
>
> The SourceOffSite people were very helpful, but it seemed that the problem
> was in VSS itself (they use the COM interface to it). Replacing a VSS DLL
> with a different version helped a bit, but the problem never went away.
So is the safe approach to run vss2svn regularly so when vss decides
to break you already have your repository converted?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Nikki Locke <in...@trumphurst.com>.
I uses SourceOffSite extensively, and found serious problems with it. Any
attempt to check out a large directory tree would result in the checkout
hanging part way through. Sometimes this would hang up the SourceOffSite
server so it accepted no further connections. At other times it was
possible to recover without rebooting the server, but the only way to get a
large tree was to get one or two directories at a time.
The SourceOffSite people were very helpful, but it seemed that the problem
was in VSS itself (they use the COM interface to it). Replacing a VSS DLL
with a different version helped a bit, but the problem never went away.
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Subversion vs CVS for document files
Posted by Steve O'Hara <so...@pivotal-solutions.co.uk>.
Before you get too carried away with the VSS bashing, it's worth
pointing out that any VSS users with any kind of sense, are not using
the VSS client, but rather SourceOffSite server. This gives you
protection against the "pulling the network cable out" problem and means
that all access to the repository is synchronised, so lessoning the
chances of collision corruptions. Indeed, it's the only way to work
with VSS over the internet.
It doesn't protect you completely from problems inherent in VSS, but it
certainly makes it very useable.
In 10 years of using it with VSS, we haven't had a single corruption or
issue manifest itself.
Steve
-----Original Message-----
From:
users-return-58433-sohara=pivotal-solutions.co.uk@subversion.tigris.org
[mailto:users-return-58433-sohara=pivotal-solutions.co.uk@subversion.tig
ris.org] On Behalf Of Robert Graf-Waczenski
Sent: 16 November 2006 11:56
To: Subversion Users
Subject: RE: Subversion vs CVS for document files
Ah, VSS bashing! Can't resist to join...
VSS, by design, depends heavily on well-synchronized system clocks of
all client computers performing checkins. In the worst case, your VSS
database is trashed completely simply because one computer checks in a
change while his system clock is on a time *before the VSS project was
created*. The main lesson to learn from this is: You can simply not
trust the VSS history because all timestamps reflected in the history
stem from the system clock that the client computer had when the checkin
was executed.
The MSDN says to this: "Make sure that you synchronize the dates and
system clocks for all Visual SourceSafe client computers".
Some development teams (such as ours here) frequently need to fiddle
with the system clocks of their computers for example to test software
behavior that depends on timestamps etc. So if the developer forgets to
re-adjust the system clock before checking in something, the VSS history
might look funny thereafter.
Robert
> -----Original Message-----
> From: Jeremy Pereira [mailto:jeremyp@jeremyp.net]
> Sent: Donnerstag, 16. November 2006 12:12
> To: Eric
> Cc: users@subversion.tigris.org
> Subject: Re: Subversion vs CVS for document files
>
>
>
> On 15 Nov 2006, at 17:06, Eric wrote:
>
> >
> > The one person who is most adamantly opposed to SVN and is so
> > adamantly pushing VSS is a partner in the business and so there is
> > no one above him who can do any of that.
>
> Google search: visual source safe corruption
>
> http://www.google.co.uk/search?hl=en&q=visual+source+safe
> +corruption&btnG=Google+Search&meta=
>
> 1.5 million results, many of which lead to articles that support the
> assertion that it should never be used by anyone ever.
>
> Alternatively, let him bring in VSS and let it speak for itself.
> From reading some of those 1.5 million articles it seems that
> unplugging your computer's network cable while in the middle of
> committing changes should be enough to corrupt your VSS repository.
> It would be unethical to do that to deliberately discredit the
> product, of course :-)
>
> >
> > He is a "my way or the highway" type whose mind typically cannot be
> > changed.
> >
> > He brings a LOT to the table and is extremely valuable, I'd say
> > crucial, to the success of this enterprise in every other way except
> > this, and that makes it difficult-to-impossible to convince the
> > other partners to overrule him on issues like this where it is
> > perceived that adequate alternatives (e.g. VSS, which they consider
> > adequate) exist.
> >
> > I am also a partner but I am only one vote.
> >
> > See what I'm up against? :-(
> >
> >
> > --------------------------------------------------------------------
> > - 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
>
---------------------------------------------------------------------
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
RE: Subversion vs CVS for document files
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
Ah, VSS bashing! Can't resist to join...
VSS, by design, depends heavily on well-synchronized system clocks of all
client computers performing checkins. In the worst case, your VSS database
is trashed completely simply because one computer checks in a change while
his system clock is on a time *before the VSS project was created*. The main
lesson to learn from this is: You can simply not trust the VSS history
because all timestamps reflected in the history stem from the system clock
that the client computer had when the checkin was executed.
The MSDN says to this: "Make sure that you synchronize the dates and system
clocks for all Visual SourceSafe client computers".
Some development teams (such as ours here) frequently need to fiddle with
the system clocks of their computers for example to test software behavior
that depends on timestamps etc. So if the developer forgets to re-adjust the
system clock before checking in something, the VSS history might look funny
thereafter.
Robert
> -----Original Message-----
> From: Jeremy Pereira [mailto:jeremyp@jeremyp.net]
> Sent: Donnerstag, 16. November 2006 12:12
> To: Eric
> Cc: users@subversion.tigris.org
> Subject: Re: Subversion vs CVS for document files
>
>
>
> On 15 Nov 2006, at 17:06, Eric wrote:
>
> >
> > The one person who is most adamantly opposed to SVN and is so
> > adamantly pushing VSS is a partner in the business and so there is
> > no one above him who can do any of that.
>
> Google search: visual source safe corruption
>
> http://www.google.co.uk/search?hl=en&q=visual+source+safe
> +corruption&btnG=Google+Search&meta=
>
> 1.5 million results, many of which lead to articles that support the
> assertion that it should never be used by anyone ever.
>
> Alternatively, let him bring in VSS and let it speak for itself.
> From reading some of those 1.5 million articles it seems that
> unplugging your computer's network cable while in the middle of
> committing changes should be enough to corrupt your VSS repository.
> It would be unethical to do that to deliberately discredit the
> product, of course :-)
>
> >
> > He is a "my way or the highway" type whose mind typically cannot be
> > changed.
> >
> > He brings a LOT to the table and is extremely valuable, I'd say
> > crucial, to the success of this enterprise in every other way
> > except this, and that makes it difficult-to-impossible to convince
> > the other partners to overrule him on issues like this where it is
> > perceived that adequate alternatives (e.g. VSS, which they consider
> > adequate) exist.
> >
> > I am also a partner but I am only one vote.
> >
> > See what I'm up against? :-(
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Jeremy Pereira <je...@jeremyp.net>.
On 15 Nov 2006, at 17:06, Eric wrote:
>
> The one person who is most adamantly opposed to SVN and is so
> adamantly pushing VSS is a partner in the business and so there is
> no one above him who can do any of that.
Google search: visual source safe corruption
http://www.google.co.uk/search?hl=en&q=visual+source+safe
+corruption&btnG=Google+Search&meta=
1.5 million results, many of which lead to articles that support the
assertion that it should never be used by anyone ever.
Alternatively, let him bring in VSS and let it speak for itself.
From reading some of those 1.5 million articles it seems that
unplugging your computer's network cable while in the middle of
committing changes should be enough to corrupt your VSS repository.
It would be unethical to do that to deliberately discredit the
product, of course :-)
>
> He is a "my way or the highway" type whose mind typically cannot be
> changed.
>
> He brings a LOT to the table and is extremely valuable, I'd say
> crucial, to the success of this enterprise in every other way
> except this, and that makes it difficult-to-impossible to convince
> the other partners to overrule him on issues like this where it is
> perceived that adequate alternatives (e.g. VSS, which they consider
> adequate) exist.
>
> I am also a partner but I am only one vote.
>
> See what I'm up against? :-(
>
>
> ---------------------------------------------------------------------
> 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
Re: Subversion vs CVS for document files
Posted by Eric <sp...@scoot.netis.com>.
At 11:16 AM 11/15/2006, Justin Patrin wrote:
<JP>>>>>If your users still have a problem with the revision number then I
suggest that they're irrationally opposed to SVN<<<<<
Yup, that's right. :-(
<JP>>>>>and you need to either: 1) make a command decision or have someone
else make one to force people to use SVN or 2) give up for using SVN until
you can get these people fired.<<<<<
The one person who is most adamantly opposed to SVN and is so adamantly
pushing VSS is a partner in the business and so there is no one above him
who can do any of that.
He is a "my way or the highway" type whose mind typically cannot be changed.
He brings a LOT to the table and is extremely valuable, I'd say crucial, to
the success of this enterprise in every other way except this, and that
makes it difficult-to-impossible to convince the other partners to overrule
him on issues like this where it is perceived that adequate alternatives
(e.g. VSS, which they consider adequate) exist.
I am also a partner but I am only one vote.
See what I'm up against? :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Justin Patrin <pa...@gmail.com>.
On 11/15/06, Eric <sp...@scoot.netis.com> wrote:
> At 12:46 PM 11/14/2006, Duncan Murdoch wrote:
>
> >> This is only a problem if you're desperately searching for problems.
>
> Good morning, Duncan.
>
> It is a problem if you're working with people who are absolutely convinced
> that it brings no benefit, and whose minds can't be changed.
>
> I can say "I can check out a complete set of files at rev X and I'm
> guaranteed that the spec matches the design matches the code matches the
> tests" and I hear "Yeah, yeah, you can do the same thing with VSS with
> tags" or some such.
>
> Never mind that it takes extra steps with VSS or CVS or most other VCSs,
> and you get it automatically with SVN.
>
> There are still document files, though, where it makes no sense to try to
> tie them to other files in a repository (e.g. company policies and
> procedures, correspondence, etc.) and it remains cumbersome to put each of
> them in its own repository. You can argue that it's not "bad", per se, to
> bump one revision level for largely-unrelated collections of such files,
> and that it does no harm, etc., but I will NEVER, ever, be able to convince
> the others on this team of that, even though I might, someday, be able to
> convince them to grudgingly accept the notion of a common rev number for a
> whole repository of RELATED files.
>
As has been mentioned before, you're not bumping the revision of any
file (the revision number is for the repository) and you're not
bumping the last changed revision for a file (this stays the same).
All you need to do is tell your users to look at the last changed
revision from 'svn info' instead of the current checkout revision.
If your users still have a problem with the revision number then I
suggest that they're irrationally opposed to SVN and you need to
either: 1) make a command decision or have someone else make one to
force people to use SVN or 2) give up for using SVN until you can get
these people fired.
(I shudder to think what your users would say about such a wonderful
system as monotone...)
--
Justin Patrin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Wed, 2006-11-15 at 10:02 -0500, Eric wrote:
> It is a problem if you're working with people who are absolutely convinced
> that it brings no benefit, and whose minds can't be changed.
>
> I can say "I can check out a complete set of files at rev X and I'm
> guaranteed that the spec matches the design matches the code matches the
> tests" and I hear "Yeah, yeah, you can do the same thing with VSS with
> tags" or some such.
>
> Never mind that it takes extra steps with VSS or CVS or most other VCSs,
> and you get it automatically with SVN.
I think the trick is to completely ignore the ambiguous 'repository'
revision number (ambiguous because any number of them might refer to
an unchanged file) and only ever refer to the one that 'svn info
filename' gives you for that particular file. Viewvc seems to do
the right thing in this respect and might be the right thing to use
for people's first exposure to the system.
> There are still document files, though, where it makes no sense to try to
> tie them to other files in a repository (e.g. company policies and
> procedures, correspondence, etc.) and it remains cumbersome to put each of
> them in its own repository.
Even if you don't make a repository per file you have to at least make
a directory per file or per group that you want to make the minimal
checkout set since there is no way check out less than a complete
directory. But, for people who just want read access for editorial
input, viewvc might be a good approach again.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Eric <sp...@scoot.netis.com>.
At 12:46 PM 11/14/2006, Duncan Murdoch wrote:
>> This is only a problem if you're desperately searching for problems.
Good morning, Duncan.
It is a problem if you're working with people who are absolutely convinced
that it brings no benefit, and whose minds can't be changed.
I can say "I can check out a complete set of files at rev X and I'm
guaranteed that the spec matches the design matches the code matches the
tests" and I hear "Yeah, yeah, you can do the same thing with VSS with
tags" or some such.
Never mind that it takes extra steps with VSS or CVS or most other VCSs,
and you get it automatically with SVN.
There are still document files, though, where it makes no sense to try to
tie them to other files in a repository (e.g. company policies and
procedures, correspondence, etc.) and it remains cumbersome to put each of
them in its own repository. You can argue that it's not "bad", per se, to
bump one revision level for largely-unrelated collections of such files,
and that it does no harm, etc., but I will NEVER, ever, be able to convince
the others on this team of that, even though I might, someday, be able to
convince them to grudgingly accept the notion of a common rev number for a
whole repository of RELATED files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 11/14/2006 12:40 PM, Les Mikesell wrote:
> On Tue, 2006-11-14 at 09:54 -0500, Duncan Murdoch wrote:
>
>> >> Actually I think the single rev# is one of the best features of SVN.
>> >> Having used "per-file" rev# systems, which deteriorate into chaos, I
>> >> far prefer the Subversion approach. Plus the fact that, in effect, a
>> >> rev# becomes a changelist.
>> >
>> > It makes sense for a 'project'. It doesn't make much sense
>> > for a collection of mostly unrelated files and it is cumbersome
>> > to put each in its own repository.
>>
>> Why not? If you just think of revision numbers as tags, they are just
>> as meaningful whether they increase sequentially or by bigger jumps.
>
> How is it meaningful - or useful - for a revision number to change
> when no related content changed? If you have a later version than
> mine, how do I know if it is different or not?
You look at the log for that file. If you want to know which version
you've got, you read "Last Changed Rev: 528" from svn info, rather than
"Revision: 595". That's the number the svn:keywords will give you if
you want to insert it into the text.
This is only a problem if you're desperately searching for problems.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion vs CVS for document files
Posted by Trent Nelson <tn...@onresolve.com>.
> > Why not? If you just think of revision numbers as tags, they are
just
> > as meaningful whether they increase sequentially or by bigger jumps.
>
> How is it meaningful - or useful - for a revision number to change
> when no related content changed? If you have a later version than
> mine, how do I know if it is different or not?
You educate your users to refer to the last changed revision of that
document, not the current repository revision. As someone else pointed
out, 'svn info <file>' will display this information.
Then, assuming you're not using a binary document format like
pdf/xls/doc, set the svn:keywords "Id" property on the file, and place
the $Id$ string on the footer of every page.
Then, when Joe wants to see if Fred is looking at the same version of
the document as he is, they compare the version # that's on the bottom
of every page.
Trent.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 14, 2006, at 11:40, Les Mikesell wrote:
>>>> Actually I think the single rev# is one of the best features of
>>>> SVN.
>>>> Having used "per-file" rev# systems, which deteriorate into
>>>> chaos, I
>>>> far prefer the Subversion approach. Plus the fact that, in
>>>> effect, a
>>>> rev# becomes a changelist.
>>>
>>> It makes sense for a 'project'. It doesn't make much sense
>>> for a collection of mostly unrelated files and it is cumbersome
>>> to put each in its own repository.
>>
>> Why not? If you just think of revision numbers as tags, they are
>> just
>> as meaningful whether they increase sequentially or by bigger jumps.
>
> How is it meaningful - or useful - for a revision number to change
> when no related content changed? If you have a later version than
> mine, how do I know if it is different or not?
I think you're thinking in CVS terms, where revisions are per-file,
and it makes sense to say things like "Revision 1.2.2 of foo is newer
than revision 1.1 of foo." And now you're confused because you're
running into the situation "Revision 48 of foo is exactly the same as
revision 32 of foo." And the problem is in the way you're expressing
this. Don't say "Revision 48 of foo"; say "Foo as it appears in
revision 48 of the repository." Then hopefully you'll see how things
are in Subversion: "Foo as it appears in revision 48 of the
repository is the same as foo as it appears in revision 32 of the
repository."
The revision is simply the number of changes that have been made to
the repository. That's all. It doesn't have any more meaning than
that; don't attach any other meaning to it.
Using revision numbers as a way to see how much work has been done on
a file isn't useful anyway, neither in Subversion nor in CVS. In
either, you can add and remove a blank line 50 times and generate 100
new revisions; doesn't mean anything useful has happened to the file.
"svn log foo" shows you the revisions of the repository in which foo
changed, and (if you've written good log messages), what changed and
why. "svn diff -rA:B foo" shows you exactly what changed between
revisions A and B. "svn blame foo" shows you the revision in which
each line was added or changed, and who did it. These are much better
ways of determining what's going on with the files than by looking at
a revision number, whether it's per-file as in CVS or per-repository
as in Subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-14 at 09:54 -0500, Duncan Murdoch wrote:
> >> Actually I think the single rev# is one of the best features of SVN.
> >> Having used "per-file" rev# systems, which deteriorate into chaos, I
> >> far prefer the Subversion approach. Plus the fact that, in effect, a
> >> rev# becomes a changelist.
> >
> > It makes sense for a 'project'. It doesn't make much sense
> > for a collection of mostly unrelated files and it is cumbersome
> > to put each in its own repository.
>
> Why not? If you just think of revision numbers as tags, they are just
> as meaningful whether they increase sequentially or by bigger jumps.
How is it meaningful - or useful - for a revision number to change
when no related content changed? If you have a later version than
mine, how do I know if it is different or not?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by John Rouillard <ro...@renesys.com>.
On Tue, Nov 14, 2006 at 07:30:02PM -0000, Nikki Locke wrote:
> John Rouillard wrote:
> > If I want to see how many versions of an ldap config file has been
> > released, I have to go to the log messages and look at all the
> > revisions and count them (or use a program to do the same). Where
> > revision 1.6 of the file tells me I have had 6 copies of the file with
> > no requirement to be able to access the repository. If I know that the
> > file is at revision 2010 in svn, does that tell me anything about the
> > number of releases of this file? It does tell me about the repository,
> > but if I only want a file number because it has no relation to the
> > repository as a whole (e.g. a document rev number) then...
>
> Just because you have (CVS style) revision 1.6 of a file, it doesn't mean
> there have only been 6 changes to the file. What about the extra 10 changes
> there might have been in a 1.2.1 branch?
>
> If you promise not to branch, then file revision numbers do tell you a small
> amount of information (which you can get in SVN from the log). But
> as soon as
> you have branches, then a file revision number becomes much less meaningful.
It does imply that this version had 5 ancestors however. Much in the
same way that the 1.2.1.6 file has 7 ancestors (1.1, 1.2,
1.2.1.1 ... 1.2.1.5).
> > In my case I have to cherry pick files at different revisions into a
> > single tag all the time because the files are loosely coupled but
> > deployed as a single entity (system configuration) but I currently
> > have 40 or so subsets of files that are totally independent. So I get
> > revision 1026 of the ssh keys files, revision 223 of the ssh config
> > files, revision 2230 of the ldap config files etc.
>
> No wonder you are having trouble coping :-)
>
> I'd be interested to know how this comes about - mainly so I can avoid
> getting myself into the same situation!
I use Config <http://www.cs.umb.edu/~rouilj#Config> for maintaining
systems. When it was first developed CVS was used for the underlying
versioning system.
The primary model of working with the system is to have all work done
on the trunk and have a series of test systems that get the current
config from the trunk. Because this is a repository of software
configuration files:
* daemon configurations (/etc/sshd/sshd_config)
* /etc/hosts files
* lists of what programs should be running on a system (think
/etc/rc setup)
* iptables firewall rules
* sets of files to deploy LDAP in our domain
* files that control the deployment of the config files
* ...
that are distributed by other mechanisms, it forms a configuration for
all the systems maintained through Config. So if something blows up,
you can back track the config to an earlier known state and reapply a
stable configuration for all the machines on the network.
Since there is very loose coupling (or no coupling) between many sets
of files. E.G. the list of sshd known_hosts has no impact on the
filesystem mount points, the file subsets can be tested in isolation
and promoted to production.
Now for production use, the tested file subset is what needs to get
deployed. So under SVN I have to pull the set of tested files (by name
and version as they may be a newer untested version of known_hosts for
example) into the production tree and push the changes to the
production hosts from the production tree of the repository. So the
production tree is composed of tested subsets of files that are
migrated from the trunk.
In CVS you simply moved the per file tag PRODUCTION from one version
to another version in the tree (leaving an old tag in place
PROD_YYYYMMDD to mark the prior production release in case you needed
to revert). A 'cvs update' of the work area that was distributed to
all the hosts on the network from the PRODUCTION sticky tag gets the
new versions of the files. It is a very simple selection method from
the (single trunk) tree in cvs.
There is no simple way in SVN to select files in a repository that are
at different versions without copying each and every file to a new
name in a new tree. But that is exactly what you need in a system
administration (or document management system). SVN isn't really able
to do this as efficiently (with respect to user effort and reduced
likelyhood of mistakes) as CVS. however the ability to move
directories around and change the structure of the repository with
ease is a win and why I changed to SVN in the first place.
So to prevent the problem I have make sure you only work on
repositories with tightly coupled files (e.g a piece of software) and
stay away from administering large installations of systems.
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Nikki Locke <in...@trumphurst.com>.
John Rouillard wrote:
> If I want to see how many versions of an ldap config file has been
> released, I have to go to the log messages and look at all the
> revisions and count them (or use a program to do the same). Where
> revision 1.6 of the file tells me I have had 6 copies of the file with
> no requirement to be able to access the repository. If I know that the
> file is at revision 2010 in svn, does that tell me anything about the
> number of releases of this file? It does tell me about the repository,
> but if I only want a file number because it has no relation to the
> repository as a whole (e.g. a document rev number) then...
Just because you have (CVS style) revision 1.6 of a file, it doesn't mean
there have only been 6 changes to the file. What about the extra 10 changes
there might have been in a 1.2.1 branch?
If you promise not to branch, then file revision numbers do tell you a small
amount of information (which you can get in SVN from the log). But as soon as
you have branches, then a file revision number becomes much less meaningful.
> In my case I have to cherry pick files at different revisions into a
> single tag all the time because the files are loosely coupled but
> deployed as a single entity (system configuration) but I currently
> have 40 or so subsets of files that are totally independent. So I get
> revision 1026 of the ssh keys files, revision 223 of the ssh config
> files, revision 2230 of the ldap config files etc.
No wonder you are having trouble coping :-)
I'd be interested to know how this comes about - mainly so I can avoid
getting myself into the same situation!
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Subversion vs CVS for document files
Posted by Méresse Christophe <ch...@nagra.com>.
> -----Original Message-----
> From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
> Sent: mardi, 14. novembre 2006 21:41
> To: John Rouillard
> Cc: users@subversion.tigris.org
> Subject: Re: Subversion vs CVS for document files
[snip]
> The problem is that the current svn log
> attaches no information to the source of the copy, only to the
> destination. It would be nice if you could look at the log of a file
> and see where it was copied *to*, as well as where it was
> copied *from*.
How happy I am when I read this ! That's for my point of view THE point
that should be developped to make subversion the perfect tool.
Currently there is no good possibility for the GUI tools to construct the
revision graph of an element and that's really a pity.
No way either to just get all the tags of a particular version, all the tags of
an element, all the branches of an element, or to ask subversion for
"the last tag on a branch" for instance.
How great it could become with the thing you are pointing out!
Christophe Méresse
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 11/14/2006 12:21 PM, John Rouillard wrote:
> On Tue, Nov 14, 2006 at 09:54:45AM -0500, Duncan Murdoch wrote:
>> On 11/14/2006 9:21 AM, Les Mikesell wrote:
>> >On Tue, 2006-11-14 at 01:38, Tim Hill wrote:
>> >>Actually I think the single rev# is one of the best features of SVN.
>> >>Having used "per-file" rev# systems, which deteriorate into chaos, I
>> >>far prefer the Subversion approach. Plus the fact that, in effect, a
>> >>rev# becomes a changelist.
>> >
>> >It makes sense for a 'project'. It doesn't make much sense
>> >for a collection of mostly unrelated files and it is cumbersome
>> >to put each in its own repository.
>>
>> Why not? If you just think of revision numbers as tags,
>
> Hence the problem. If you think of revision numbers as the count of
> the number of revisions of the file not the repository. A file
> activity counter if you will, then you loose information with the
> repository version number. Both ways are right and wrong depending on
> how the files relate to each other.
That's not a good measure of the amount of activity, because a rev
number can change when you fix a typo or change spaces to tabs, or when
you completely rewrite the file. A better measure of the amount of
activity is the size of a diff of the file, but even that is imperfect:
changing spaces to tabs may look big if it affects lots of lines, even
though it is nearly content free.
> In my case I have to cherry pick files at different revisions into a
> single tag all the time because the files are loosely coupled but
> deployed as a single entity (system configuration) but I currently
> have 40 or so subsets of files that are totally independent. So I get
> revision 1026 of the ssh keys files, revision 223 of the ssh config
> files, revision 2230 of the ldap config files etc.
>
> (These revisions aren't always the same version I would get by
> checking out the HEAD revision of the tree. I have sort of abandoned
> this because of how difficult it is to track this where it was easy
> under CVS with floating tags, but I digress.)
>
>> they are just
>> as meaningful whether they increase sequentially or by bigger jumps.
>
> If I want to see how many versions of an ldap config file has been
> released, I have to go to the log messages and look at all the
> revisions and count them (or use a program to do the same).
That's where svn is lacking, it doesn't give you an easy way to count
the tags on a file, which cvs does. This doesn't have anything to do
with revision numbers on files versus the repository, it has to do with
limitations in current svn tools.
I think you could write a script to search the entire log to find how
often a file had been copied to the tags hierarchy, and list all the
tags, but it would be slow. The problem is that the current svn log
attaches no information to the source of the copy, only to the
destination. It would be nice if you could look at the log of a file
and see where it was copied *to*, as well as where it was copied *from*.
> Where
> revision 1.6 of the file tells me I have had 6 copies of the file with
> no requirement to be able to access the repository. If I know that the
> file is at revision 2010 in svn, does that tell me anything about the
> number of releases of this file? It does tell me about the repository,
> but if I only want a file number because it has no relation to the
> repository as a whole (e.g. a document rev number) then...
Rev 1.6 doesn't tell you about the number of releases, only the number
of revisions on the trunk, but as I said above, that doesn't really
measure how much activity there has been.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Wed, 2006-11-15 at 15:58 -0500, John Rouillard wrote:
> Actually you don't want a branch for each system under Config (or most
> other high level tools that handle system configuration).
I'm not sure, but I think I want branches more than I want a higher
level tool. At the moment I'm not so interested in something to
control the configurations as in being able to view the contents
and changes over any time interval and the differences from one
machine to another.
> Config was designed to utilize templates driven from a "database"
> description of the configuration of the system. So you never check in
> a file for a host but for a class of host. E.G. external ssh server or
> internal ssh server, ldap server for a given site etc. The file for
> the host is a generated item not a primary version controlled item.
I want to be able to make changes directly on the machines - and
allow things like normal system updates to make changes. I'd just
like to propagate them back to a common repository after the fact
in a way that makes it easy to track what those changes were. I
do this with CVS and a few files from a few machines now, but it
would be nicer to have a way that permits comparing changes between
machines more easily.
> > but I haven't come up with a way to import
> > things in a way that gives them a common parent and maintains the
> > common base versions on a trunk with only the differences in the
> > branches.
>
> Yup that's the problem. You end up managing a number of individual
> systems rather than managing a configuration across systems.
That's not a problem for me. Most of my machines that are similar
actually start as complete disk image copies from a master. The parts
that are changed from that are usually for individual differences. I
just want to be able to easily see what those are and when they
were done.
> Well you can create makefiles/scripts that control propagation of
> changes/diffs but I think you are going in the wrong direction. IMO
> you need to be looking at creating master templates, controlling those
> and generating from the templates the individual configs for the
> hosts. Trying to go the other way is much more difficult.
I don't want to get in a fight with RPM-based system updates or
additions by on-site people that know more about local IP addressing
and routes than a central manager might, and if I really need a major
change I can always clone the disks again.
> However this is getting of topic for this list and is much more suited
> for a list like: config-mgmt at lopsa.org.
I'm not so sure. What I really want is to track a bunch of similar
versions of files which seems like something a version control system
should be good at. The trick is to get them into the system in a
way that maintains the concept of a starting point that the branches
are copied from. I suppose at the expense of 2 extra copies of the
/etc tree on each server I could start with a working copy of the master
as cloned, then script something to copy to a branch when the hostname
is changed and periodically copy in current files and commit them.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by John Rouillard <ro...@renesys.com>.
On Tue, Nov 14, 2006 at 03:01:38PM -0600, Les Mikesell wrote:
> On Tue, 2006-11-14 at 12:21 -0500, John Rouillard wrote:
>
> > In my case I have to cherry pick files at different revisions into a
> > single tag all the time because the files are loosely coupled but
> > deployed as a single entity (system configuration) but I currently
> > have 40 or so subsets of files that are totally independent. So I get
> > revision 1026 of the ssh keys files, revision 223 of the ssh config
> > files, revision 2230 of the ldap config files etc.
>
> I think what you really want is to maintain the systems as branches
> in the first place,
Actually you don't want a branch for each system under Config (or most
other high level tools that handle system configuration).
Config was designed to utilize templates driven from a "database"
description of the configuration of the system. So you never check in
a file for a host but for a class of host. E.G. external ssh server or
internal ssh server, ldap server for a given site etc. The file for
the host is a generated item not a primary version controlled item.
It is less about managing a single system and more amount managing a
constellation of systems based on what they are doing. I can change
services from one box to another by modifying the database and
re-distributing the result of applying the database to the files in
the repository.
> but I haven't come up with a way to import
> things in a way that gives them a common parent and maintains the
> common base versions on a trunk with only the differences in the
> branches.
Yup that's the problem. You end up managing a number of individual
systems rather than managing a configuration across systems.
> Has anyone worked out a scheme for this where the
> (slightly) differing versions already exist as a starting point,
> then ongoing changes are made in one of the branches and may or
> may not be propagated to the trunk and other branches? I'd love
> to be able to 'svn diff' all or any configs from one machine to
> another as well as different timeframes.
Well you can create makefiles/scripts that control propagation of
changes/diffs but I think you are going in the wrong direction. IMO
you need to be looking at creating master templates, controlling those
and generating from the templates the individual configs for the
hosts. Trying to go the other way is much more difficult.
However this is getting of topic for this list and is much more suited
for a list like: config-mgmt at lopsa.org.
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-14 at 12:21 -0500, John Rouillard wrote:
> In my case I have to cherry pick files at different revisions into a
> single tag all the time because the files are loosely coupled but
> deployed as a single entity (system configuration) but I currently
> have 40 or so subsets of files that are totally independent. So I get
> revision 1026 of the ssh keys files, revision 223 of the ssh config
> files, revision 2230 of the ldap config files etc.
I think what you really want is to maintain the systems as branches
in the first place, but I haven't come up with a way to import
things in a way that gives them a common parent and maintains the
common base versions on a trunk with only the differences in the
branches. Has anyone worked out a scheme for this where the
(slightly) differing versions already exist as a starting point,
then ongoing changes are made in one of the branches and may or
may not be propagated to the trunk and other branches? I'd love
to be able to 'svn diff' all or any configs from one machine to
another as well as different timeframes.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by John Rouillard <ro...@renesys.com>.
On Tue, Nov 14, 2006 at 09:54:45AM -0500, Duncan Murdoch wrote:
> On 11/14/2006 9:21 AM, Les Mikesell wrote:
> >On Tue, 2006-11-14 at 01:38, Tim Hill wrote:
> >>Actually I think the single rev# is one of the best features of SVN.
> >>Having used "per-file" rev# systems, which deteriorate into chaos, I
> >>far prefer the Subversion approach. Plus the fact that, in effect, a
> >>rev# becomes a changelist.
> >
> >It makes sense for a 'project'. It doesn't make much sense
> >for a collection of mostly unrelated files and it is cumbersome
> >to put each in its own repository.
>
> Why not? If you just think of revision numbers as tags,
Hence the problem. If you think of revision numbers as the count of
the number of revisions of the file not the repository. A file
activity counter if you will, then you loose information with the
repository version number. Both ways are right and wrong depending on
how the files relate to each other.
In my case I have to cherry pick files at different revisions into a
single tag all the time because the files are loosely coupled but
deployed as a single entity (system configuration) but I currently
have 40 or so subsets of files that are totally independent. So I get
revision 1026 of the ssh keys files, revision 223 of the ssh config
files, revision 2230 of the ldap config files etc.
(These revisions aren't always the same version I would get by
checking out the HEAD revision of the tree. I have sort of abandoned
this because of how difficult it is to track this where it was easy
under CVS with floating tags, but I digress.)
> they are just
> as meaningful whether they increase sequentially or by bigger jumps.
If I want to see how many versions of an ldap config file has been
released, I have to go to the log messages and look at all the
revisions and count them (or use a program to do the same). Where
revision 1.6 of the file tells me I have had 6 copies of the file with
no requirement to be able to access the repository. If I know that the
file is at revision 2010 in svn, does that tell me anything about the
number of releases of this file? It does tell me about the repository,
but if I only want a file number because it has no relation to the
repository as a whole (e.g. a document rev number) then...
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 11/14/2006 9:21 AM, Les Mikesell wrote:
> On Tue, 2006-11-14 at 01:38, Tim Hill wrote:
>> Actually I think the single rev# is one of the best features of SVN.
>> Having used "per-file" rev# systems, which deteriorate into chaos, I
>> far prefer the Subversion approach. Plus the fact that, in effect, a
>> rev# becomes a changelist.
>
> It makes sense for a 'project'. It doesn't make much sense
> for a collection of mostly unrelated files and it is cumbersome
> to put each in its own repository.
Why not? If you just think of revision numbers as tags, they are just
as meaningful whether they increase sequentially or by bigger jumps.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-14 at 01:38, Tim Hill wrote:
> Actually I think the single rev# is one of the best features of SVN.
> Having used "per-file" rev# systems, which deteriorate into chaos, I
> far prefer the Subversion approach. Plus the fact that, in effect, a
> rev# becomes a changelist.
It makes sense for a 'project'. It doesn't make much sense
for a collection of mostly unrelated files and it is cumbersome
to put each in its own repository.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Andy Levy <an...@gmail.com>.
On 11/14/06, Eric <sp...@scoot.netis.com> wrote:
> At 02:38 AM 11/14/2006, Tim Hill wrote:
>
> <TH>>>>>Why are your users raising hell? What is the workflow that needs
> per-file rev# info?<<<<<
>
> Good morning, Tim.
>
> I'm not sure. I guess it's just that we're all accustomed to per-file rev
> numbers. And for documents, it does make some sense.
svn info <filename> from your working copy (or you can pass a URL)
includes in its output the Last Changed Rev which is the last
repository revision number which contains a change to that file.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Tim Hill <dr...@comcast.net>.
Occasionally someone raises the non-sequential rev# thing, and its
usually for one of two reasons: build numbers and documentation
revision. Apparently some users get worried when a doc number of
build number goes from 1234 to 1567 in a single jump. Usually, this
can be fixed by pointing out that the only really important thing
(which svn provides as a strong guaranteee) is that newer versions of
a document have numerically greater revision numbers.
In fact, in this situation, I usually sell the "virtues" of the
single rev# model -- when you go to a release of a set of files/
documents, they are automatically get the same rev#, so you can
easily tell at a glance that two docs do or do not come from the same
release -- very nice.
--Tim
On Nov 14, 2006, at 3:24 AM, Eric wrote:
> At 02:38 AM 11/14/2006, Tim Hill wrote:
>
> <TH>>>>>Why are your users raising hell? What is the workflow that
> needs per-file rev# info?<<<<<
>
> Good morning, Tim.
>
> I'm not sure. I guess it's just that we're all accustomed to per-
> file rev numbers. And for documents, it does make some sense.
> That's why we're looking for something else to use for documents.
>
>
> ---------------------------------------------------------------------
> 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
Re: Subversion vs CVS for document files
Posted by Eric <sp...@scoot.netis.com>.
At 02:38 AM 11/14/2006, Tim Hill wrote:
<TH>>>>>Why are your users raising hell? What is the workflow that needs
per-file rev# info?<<<<<
Good morning, Tim.
I'm not sure. I guess it's just that we're all accustomed to per-file rev
numbers. And for documents, it does make some sense. That's why we're
looking for something else to use for documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Tim Hill <dr...@comcast.net>.
Actually I think the single rev# is one of the best features of SVN.
Having used "per-file" rev# systems, which deteriorate into chaos, I
far prefer the Subversion approach. Plus the fact that, in effect, a
rev# becomes a changelist.
Why are your users raising hell? What is the workflow that needs per-
file rev# info?
--Tim
On Nov 9, 2006, at 9:48 AM, Eric wrote:
> At 12:01 PM 11/9/2006, Thomas Harold wrote:
>
> <TH>>>>>What doesn't work well (IMO) at the moment is pulling down
> partial working copies or deep-selective checkouts. SVN doesn't
> (yet) offer any easy way to pull down anything other then full blow
> project trees into the local working copy.<<<<<
>
> Right, that and the fact that the rev number for a whole repository
> is bumped whenever one file is revised.
>
> I know why this is done and I have no particular problem with it
> (would have preferred the option of revving up individual files but
> it's not a big deal). But, others on my team are raising holy hell
> about it and one is close to flat refusing to use it.
>
> I also prefer to use a single tool for everything but if separate
> tools do the job better, I'm not adamantly against the idea.
>
>
> ---------------------------------------------------------------------
> 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
Re: Subversion vs CVS for document files
Posted by Eric <sp...@scoot.netis.com>.
At 12:01 PM 11/9/2006, Thomas Harold wrote:
<TH>>>>>What doesn't work well (IMO) at the moment is pulling down partial
working copies or deep-selective checkouts. SVN doesn't (yet) offer any
easy way to pull down anything other then full blow project trees into the
local working copy.<<<<<
Right, that and the fact that the rev number for a whole repository is
bumped whenever one file is revised.
I know why this is done and I have no particular problem with it (would
have preferred the option of revving up individual files but it's not a big
deal). But, others on my team are raising holy hell about it and one is
close to flat refusing to use it.
I also prefer to use a single tool for everything but if separate tools do
the job better, I'm not adamantly against the idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs CVS for document files
Posted by Thomas Harold <tg...@tgharold.com>.
Eric Poole wrote:
>
> I've forgotten ... can any of you tell me whether CVS allows individual
> file checkout and checkin rather than (or in addition to) whole
> directories like SVN?
>
> I just finished installing TortoiseSVN and working my way past an error
> or two in the install instructions, along with my own native inability
> to RTFM :-) ... and I got to wondering if I should use SVN for code
> trees and CVS for documentation (specs and user manuals and such).
>
> I could install TortoiseCVS right along side TortoiseSVN and use them both.
Um, you can add/commit individual files just fine in SVN. Unless I
misunderstand what you meant.
What doesn't work well (IMO) at the moment is pulling down partial
working copies or deep-selective checkouts. SVN doesn't (yet) offer any
easy way to pull down anything other then full blow project trees into
the local working copy.
So typically you end up with more files on the local drive then what you
happen to be working on at a particular instant in time.
(I prefer to use a single tool for everything. Keeps things less
confusing. We're actually using SVN to manage large collections of
things like documents, spreadsheets and data sets. Which is very far
away from using SVN to develop software.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Subversion vs CVS for document files
Posted by Eric Poole <er...@rkt-tech.com>.
I've forgotten ... can any of you tell me whether CVS allows individual
file checkout and checkin rather than (or in addition to) whole directories
like SVN?
I just finished installing TortoiseSVN and working my way past an error or
two in the install instructions, along with my own native inability to RTFM
:-) ... and I got to wondering if I should use SVN for code trees and CVS
for documentation (specs and user manuals and such).
I could install TortoiseCVS right along side TortoiseSVN and use them both.
Does that sound like a reasonable approach?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Les Mikesell <le...@gmail.com>.
On Wed, 2006-11-08 at 14:43 -0700, Andy Peters wrote:
> > Subversion, OTOH, by default uses the "Copy-Modify-Merge" pattern,
> > which
> > has some downsides on first glance if you are used to the VSS
> > patterns.
> > With the Subversion pattern, the user is not notified about changes by
> > others until the user *commits* his own changes.
>
> To be completely clear: the user is not notified about changes
> committed by others until after the user attempts to commit his own
> changes. If any changes were made, there's a conflict and the user
> has to resolve it before he's allowed to commit his changes.
Yes, but that's assuming the user doesn't bother to update to
pick up the work done by others during the time while he
is adding these incompatible changes. If that time interval
is large he might have been able to avoid the problem easily.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Concurrent versioning = spawn of the devil?
Posted by Andy Peters <de...@latke.net>.
On Nov 8, 2006, at 1:58 AM, Robert Graf-Waczenski wrote:
> Subversion, OTOH, by default uses the "Copy-Modify-Merge" pattern,
> which
> has some downsides on first glance if you are used to the VSS
> patterns.
> With the Subversion pattern, the user is not notified about changes by
> others until the user *commits* his own changes.
To be completely clear: the user is not notified about changes
committed by others until after the user attempts to commit his own
changes. If any changes were made, there's a conflict and the user
has to resolve it before he's allowed to commit his changes.
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Concurrent versioning = spawn of the devil?
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
Duh. I'm frequently using the privately-coined abbreviation "LMM"
in my text below. Instead i meant to write "LMU", which is supposed
to stand for "Lock-Modify-Unlock", so please do so here on the text:
s/LMM/LMU/g
And, of course, neither "LMU" or "CMM" are in any way official acronyms.
Robert
> -----Original Message-----
> From: Robert Graf-Waczenski [mailto:rgw@lsoft.com]
> Sent: Mittwoch, 8. November 2006 09:58
> To: users@subversion.tigris.org
> Subject: RE: Concurrent versioning = spawn of the devil?
>
>
> I can't point you to resources on the net, but I also had a discussion
> with a co-worker about this issue yesterday, so I took the time to
> summarize some parts of our discussion:
>
> To repeat other resources, here's the issue that is under discussion:
>
> VSS uses two different patterns, one is what the Subversion documentation
> calls "Lock-Modify-Unlock", i.e. before a user can edit a given file
> in his local working copy, he must acquire an exclusive lock to the file
> from the VSS server (or manually change the file to be no longer
> read-only anymore, but let's ignore this option). If someone else has
> a lock already (i.e. has VSS-checked-out the file), then the lock will
> be denied. The second pattern is a slight variation of the first, and
> is achieved by configuring VSS to support multiple checkouts, which
> means that the user still has to acquire a lock but several users
> can have a lock on the same file, meaning that several users have
> checked out the file, hence the term "multiple checkout". Normally
> you choose the first approach for binary files and the second approach
> for non-binary files because the latter can not be merged.
>
> Subversion, OTOH, by default uses the "Copy-Modify-Merge" pattern, which
> has some downsides on first glance if you are used to the VSS patterns.
> With the Subversion pattern, the user is not notified about changes by
> others until the user *commits* his own changes. In VSS, you are
> warned that
> you have not yet checked out the file and are asked to perform a checkout.
> And when you do checkout the file, you get its current version from the
> repsitory and in this way you get to see the other user's changes *before*
> you even start editing.
>
> So, when trying to compare the VSS patterns with the Subversion pattern,
> you first must make clear *which* of the two VSS patterns you are
> comparing
> against, because the good news is: Subversion also supports one of the
> two VSS patterns, namely the strict variant! What you have to do is
> set the "svn:needs-lock" property on all files that you want to be
> handled according to the stricter of the two VSS patterns. The SVN client
> then behaves much similarly to the VSS client, i.e. the read-only flag
> on the file is set etc.
> However, if your partner is in love with the multi-checkout variant of
> the VSS pattern (i think he is referring to this one since you are
> having such a hard time in your discussions with him), then you are of
> course talking about files that can be merged, i.e. non-binary files,
> right? Because otherwise, VSS would force you to use the strict pattern
> and this variant is supported in SVN, as said above.
>
> The less strict variant, however, is not supported in SVN, so we need some
> arguments why the SVN Copy-Modify-Merge does not equal "bad" and why the
> VSS "Shared Lock-Modify-Unlock" does not necessarily equal "good".
>
> Why is SVN's CMM not bad?
> -------------------------
>
> The main reason in my eyes is: If you have good merging tools, CMM is
> actually fine and there are no problems whatsoever with it. The use case
> simply is: "I want my changes to not silently overwrite changes that
> others have made to the same file". Learning that SVN waits to inform you
> about a new version in the repository as late as when you try to commit
> sounds "evil" on first glance because one is tempted to think that your
> changes are lost and you are forced to redo them. No. Wrong. Instead,
> you still have your local changes and you are asked to merge the changes
> from the repository with your own changes, yielding a merged version of
> the file. So, your changes are not lost. VSS users typically
> *hate* merging
> simply because the default merging window of the VSS explorer is such
> an awful tool to work with: No syntax coloring, no obvious pointers on
> how to apply which of the two changes and what the result will look like.
> (It *does* display all the information you need, but I frequently have
> a hard time performing a merge operation and it often leaves me unsure
> if the result is ok or not.)
>
> Why is VSS's LMM pattern not good?
> ----------------------------------
>
> In my eyes the main problem with this is that it gives you bogus
> protection. Since we are talking about a scenario where the file can be
> checked out by several peer workers (see above why), the warning that
> VSS issues to you is nothing that protects you from someone else also
> checking out the file and then checks it back in before you have time
> to checkin. So you are under the false assumption that your changes
> can be applied without conflicts and are then presented with a merge
> conflict when you check in. Note that i'm not saying that the LMM pattern
> is "bad", i'm only saying that the pattern by itself is no improvement
> versus the CMM pattern. Both patterns rely on the worker itself to make
> sure that his local changes are correctly merged with the changes that
> have occurred since the local version was retrieved from the repo.
>
> Who is the winner then?
> -----------------------
>
> This is a SVN list. So guess who wins?
>
> My personal opinion is that the LMM model is more honest to you. It does
> not attempt to give you protection that is not possible. *Any* revision
> control system must face the problem that your working copy is outdated
> vs. the current repository. Think of it as a time window issue: VSS gives
> you a short heads-up that there *might* be a new version of the file and
> gives you that new verison immediately before you begin with your changes.
> This approach sound appealing on first glance. The fact that the repo
> version of the file can be newer *again* when you try to check in is
> easily overlooked and leads to the false observation that VSS is better
> in this regard. SVN instead doesn't even try to tell you that there might
> be other changes to the file in the repository. You simply learn to
> assume that there can be changes, so you learn to update your working copy
> before you start making changes and expect naturally that you may
> encounter
> an even more recent repository when you commit your changes.
>
> I'd suggest two things:
>
> 1) If your discussion evolves around the multi-checkout variant, then
> educate him about the equation "shared file locking" = "bogus protection"
>
> 2) If you are talking about the single-checkout variant, then learn about
> SVN's support for exclusive locks with "svn:needs-lock", with this, you
> get a behavior that is as strict as VSS's and also marks your local copy
> as "read only".
>
> Robert
>
> > -----Original Message-----
> > From: Eric [mailto:spamsink@scoot.netis.com]
> > Sent: Mittwoch, 8. November 2006 07:10
> > To: users@subversion.tigris.org
> > Subject: Concurrent versioning = spawn of the devil?
> >
> >
> >
> > Can someone point me to some information on the web that I can use to
> > convince my co-developer that concurrent versioning, with
> unlocked files,
> > isn't the absolute evil that he claims it is?
> >
> > I've been arguing with him about it for half the evening and I'm
> > just about
> > out of ideas...
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Concurrent versioning = spawn of the devil?
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
I can't point you to resources on the net, but I also had a discussion
with a co-worker about this issue yesterday, so I took the time to
summarize some parts of our discussion:
To repeat other resources, here's the issue that is under discussion:
VSS uses two different patterns, one is what the Subversion documentation
calls "Lock-Modify-Unlock", i.e. before a user can edit a given file
in his local working copy, he must acquire an exclusive lock to the file
from the VSS server (or manually change the file to be no longer
read-only anymore, but let's ignore this option). If someone else has
a lock already (i.e. has VSS-checked-out the file), then the lock will
be denied. The second pattern is a slight variation of the first, and
is achieved by configuring VSS to support multiple checkouts, which
means that the user still has to acquire a lock but several users
can have a lock on the same file, meaning that several users have
checked out the file, hence the term "multiple checkout". Normally
you choose the first approach for binary files and the second approach
for non-binary files because the latter can not be merged.
Subversion, OTOH, by default uses the "Copy-Modify-Merge" pattern, which
has some downsides on first glance if you are used to the VSS patterns.
With the Subversion pattern, the user is not notified about changes by
others until the user *commits* his own changes. In VSS, you are warned that
you have not yet checked out the file and are asked to perform a checkout.
And when you do checkout the file, you get its current version from the
repsitory and in this way you get to see the other user's changes *before*
you even start editing.
So, when trying to compare the VSS patterns with the Subversion pattern,
you first must make clear *which* of the two VSS patterns you are comparing
against, because the good news is: Subversion also supports one of the
two VSS patterns, namely the strict variant! What you have to do is
set the "svn:needs-lock" property on all files that you want to be
handled according to the stricter of the two VSS patterns. The SVN client
then behaves much similarly to the VSS client, i.e. the read-only flag
on the file is set etc.
However, if your partner is in love with the multi-checkout variant of
the VSS pattern (i think he is referring to this one since you are
having such a hard time in your discussions with him), then you are of
course talking about files that can be merged, i.e. non-binary files,
right? Because otherwise, VSS would force you to use the strict pattern
and this variant is supported in SVN, as said above.
The less strict variant, however, is not supported in SVN, so we need some
arguments why the SVN Copy-Modify-Merge does not equal "bad" and why the
VSS "Shared Lock-Modify-Unlock" does not necessarily equal "good".
Why is SVN's CMM not bad?
-------------------------
The main reason in my eyes is: If you have good merging tools, CMM is
actually fine and there are no problems whatsoever with it. The use case
simply is: "I want my changes to not silently overwrite changes that
others have made to the same file". Learning that SVN waits to inform you
about a new version in the repository as late as when you try to commit
sounds "evil" on first glance because one is tempted to think that your
changes are lost and you are forced to redo them. No. Wrong. Instead,
you still have your local changes and you are asked to merge the changes
from the repository with your own changes, yielding a merged version of
the file. So, your changes are not lost. VSS users typically *hate* merging
simply because the default merging window of the VSS explorer is such
an awful tool to work with: No syntax coloring, no obvious pointers on
how to apply which of the two changes and what the result will look like.
(It *does* display all the information you need, but I frequently have
a hard time performing a merge operation and it often leaves me unsure
if the result is ok or not.)
Why is VSS's LMM pattern not good?
----------------------------------
In my eyes the main problem with this is that it gives you bogus
protection. Since we are talking about a scenario where the file can be
checked out by several peer workers (see above why), the warning that
VSS issues to you is nothing that protects you from someone else also
checking out the file and then checks it back in before you have time
to checkin. So you are under the false assumption that your changes
can be applied without conflicts and are then presented with a merge
conflict when you check in. Note that i'm not saying that the LMM pattern
is "bad", i'm only saying that the pattern by itself is no improvement
versus the CMM pattern. Both patterns rely on the worker itself to make
sure that his local changes are correctly merged with the changes that
have occurred since the local version was retrieved from the repo.
Who is the winner then?
-----------------------
This is a SVN list. So guess who wins?
My personal opinion is that the LMM model is more honest to you. It does
not attempt to give you protection that is not possible. *Any* revision
control system must face the problem that your working copy is outdated
vs. the current repository. Think of it as a time window issue: VSS gives
you a short heads-up that there *might* be a new version of the file and
gives you that new verison immediately before you begin with your changes.
This approach sound appealing on first glance. The fact that the repo
version of the file can be newer *again* when you try to check in is
easily overlooked and leads to the false observation that VSS is better
in this regard. SVN instead doesn't even try to tell you that there might
be other changes to the file in the repository. You simply learn to
assume that there can be changes, so you learn to update your working copy
before you start making changes and expect naturally that you may encounter
an even more recent repository when you commit your changes.
I'd suggest two things:
1) If your discussion evolves around the multi-checkout variant, then
educate him about the equation "shared file locking" = "bogus protection"
2) If you are talking about the single-checkout variant, then learn about
SVN's support for exclusive locks with "svn:needs-lock", with this, you
get a behavior that is as strict as VSS's and also marks your local copy
as "read only".
Robert
> -----Original Message-----
> From: Eric [mailto:spamsink@scoot.netis.com]
> Sent: Mittwoch, 8. November 2006 07:10
> To: users@subversion.tigris.org
> Subject: Concurrent versioning = spawn of the devil?
>
>
>
> Can someone point me to some information on the web that I can use to
> convince my co-developer that concurrent versioning, with unlocked files,
> isn't the absolute evil that he claims it is?
>
> I've been arguing with him about it for half the evening and I'm
> just about
> out of ideas...
>
>
> ---------------------------------------------------------------------
> 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