Program Stalls (Re: SmartSVN Professional Evaluation)

[Eric]

(This is an email being sent to the support department at Syntevo, the
SmartSVN vendor, and is also being copied to the Subversion mailing list...)

Good evening...

We are running into a problem with SmartSVN, both the Foundation version
and the Professional version (with the 31-day evaluation license).

If someone has a file checked out and locked, SmartSVN will let me check
out the file and make my changes to it without warning me that the file is
locked. That's bad enough, but then when I go to check it back in SmartSVN
just hangs and give me the perpetual hourglass and gives me no way to
cancel the operation or even stop the program other than calling up Task
Manager and killing it.

If I then go in to the repository (as the user that locked the file) and
unlock it, SmartSVN still just stays in the "waiting" mode, won't detect
that the file has been unlocked. The only way I can get out of it is to go
into Windows Task Manager and kill the process.

This is a total show-stopper.

Now, I KNOW that one is not supposed to lock files when one checks them out
from Subversion, it defeats the whole concurrent versioning paradigm ...
but my co-developer on this project adamantly refuses to use Subversion at
all if he can't lock files, and also refuses to use it if it has to be used
from the command line ... and so unless we can get SmartSVN to handle
locked files in a logical manner (i.e. complain about the lock and refuse
to check in the file), he'll be back insisting that we use Visual Source
Safe with all of the liabilities that that entails.

(For the folks on the Subversion mailing list ... Yeah, I gave him all the
stuff that you guys gave me earlier today about VSS and how bad it is and
why. Didn't do any good.) :-(

I thought it might be an oddity of the Foundation version, so I got the
31-day evaluation license for the Professional version, and it's doing the
same thing.

Subversion version is 1.3.2, and SmartSVN version is 2.0.7. Connection is
via svn+ssh.

I rather badly need a fix for this ... any ideas?

Eric Poole

[Eric]

I realize this isn't really a Subversion problem and so I should be asking
on some other mailing list like Apache, but I'm trying to come up with an
alternative to SmartSVN (to get around that file locking problem described
in an earlier message) before my co-developer gets to the point where he
absolutely refuses to consider Subversion any further (he's probably there
now, actually, but I'm hoping not)...

Trying to load mod_dav_svn.so and mod_authz_svn.so into Apache so I can try
WebDAV, and I get:

Cannot load /etc/httpd/modules/mod_dav_svn.so into server:
/etc/httpd/modules/mod_dav_svn.so: undefined symbol: dav_xml_get_cdata

As an experiment, if I comment out the mod_dav_svn.so line in
conf.d/subversion.conf, so that only mod_authz_svn.so loads, I get:

Cannot load /etc/httpd/modules/mod_authz_svn.so into server:
/etc/httpd/modules/mod_authz_svn.so: undefined symbol: dav_svn_split_uri

I had to comment out both the mod_dav_svn.so and mod_authz_svn.so lines in
subversion.conf in order to get Apache to run at all.

Anyone know how I can fix that?

[Eric]

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...

[Mark]

http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html#svn.basic.vsn-models.copy-merge

On 11/7/06, Eric <***@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-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>
>


--
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."

[Kenneth Porter]

--On Wednesday, November 08, 2006 1:10 AM -0500 Eric
<***@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.

[Eric]

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...

[Robert Graf-Waczenski]

> <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

[Eric]

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 ... :-(

[Thomas Hemmer]

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

[Thomas Harold]

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.

[Ruslan Sivak]

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-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org

[Robert Graf-Waczenski]

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:***@scoot.netis.com]
> Sent: Mittwoch, 8. November 2006 07:10
> To: ***@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-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

[Robert Graf-Waczenski]

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:***@lsoft.com]
> Sent: Mittwoch, 8. November 2006 09:58
> To: ***@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:***@scoot.netis.com]
> > Sent: Mittwoch, 8. November 2006 07:10
> > To: ***@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-***@subversion.tigris.org
> > For additional commands, e-mail: users-***@subversion.tigris.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

[Matt Sickler]

On 11/8/06, Robert Graf-Waczenski <***@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.

[Andy Peters]

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

[Eric Poole]

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?

[Thomas Harold]

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.)

[Eric]

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.

[Tim Hill]

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-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

[Eric]

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.

[Andy Levy]

On 11/14/06, Eric <***@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.

[Tim Hill]

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-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

[Les Mikesell]

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
***@gmail.com

[Duncan Murdoch]

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

[John Rouillard]

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

[Nikki Locke]

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/

[John Rouillard]

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

[Duncan Murdoch]

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

[Méresse Christophe]

> -----Original Message-----
> From: Duncan Murdoch [mailto:***@stats.uwo.ca]
> Sent: mardi, 14. novembre 2006 21:41
> To: John Rouillard
> Cc: ***@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

[Les Mikesell]

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
***@gmail.com

[John Rouillard]

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

[Les Mikesell]

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
***@gmail.com

[Les Mikesell]

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
***@gmail.com

[Duncan Murdoch]

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

[Les Mikesell]

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
***@gmail.com

[Duncan Murdoch]

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

[Les Mikesell]

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
***@gmail.com

[Duncan Murdoch]

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

[Les Mikesell]

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
***@gmail.com

[Ryan Schmidt]

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.

[Tim Hill]

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
> ***@gmail.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

[Les Mikesell]

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
***@gmail.com

[Tim Hill]

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
> ***@gmail.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

[Talden]

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 <***@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

[Jeremy Pereira]

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
> ***@gmail.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>
>

[Eric]

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.

[Justin Patrin]

On 11/15/06, Eric <***@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

[Eric]

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? :-(

[Tim Hill]

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.

[Ted Dennison]

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:***@ssd.fsi.com
Home - mailto:***@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/~dennison/Ted/TED.html

[Tim Hill]

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:***@ssd.fsi.com
> Home - mailto:***@telepath.com (Yahoo: Ted_Dennison)
> Homepage - http://www.telepath.com/~dennison/Ted/TED.html
>

[Jeremy Pereira]

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-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>
>

[Robert Graf-Waczenski]

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.net]
> Sent: Donnerstag, 16. November 2006 12:12
> To: Eric
> Cc: ***@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-***@subversion.tigris.org
> > For additional commands, e-mail: users-***@subversion.tigris.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

[Steve O'Hara]

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-***@subversion.tigris.org
[mailto:users-return-58433-sohara=pivotal-***@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.net]
> Sent: Donnerstag, 16. November 2006 12:12
> To: Eric
> Cc: ***@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-***@subversion.tigris.org
> > For additional commands, e-mail: users-***@subversion.tigris.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@subversion.tigris.org
For additional commands, e-mail: users-***@subversion.tigris.org

[Nikki Locke]

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/

[Les Mikesell]

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
***@gmail.com

[Thomas Harold]

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.)

[Robert Graf-Waczenski]

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

[Kenneth Porter]

--On Friday, November 17, 2006 9:08 AM +0100 Robert Graf-Waczenski
<***@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.

[Ryan Schmidt]

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.

[Les Mikesell]

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
***@gmail.com

[Ryan Schmidt]

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.

[Trent Nelson]

> > 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.

[Duncan Murdoch]

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

[Les Mikesell]

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
***@gmail.com

[Erik Huelsmann]

On 11/8/06, Eric <***@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.

[Eric Poole]

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.

[Erik Huelsmann]

On 11/9/06, Eric Poole <***@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.

[Tim Hill]

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 <***@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-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>

[Mark]

What linux are you running? It sounds like the mod_dav module itself
is not loaded. You need that to get mod_dav_svn to work :)


On 11/7/06, Eric <***@scoot.netis.com> wrote:
>
> I realize this isn't really a Subversion problem and so I should be asking
> on some other mailing list like Apache, but I'm trying to come up with an
> alternative to SmartSVN (to get around that file locking problem described
> in an earlier message) before my co-developer gets to the point where he
> absolutely refuses to consider Subversion any further (he's probably there
> now, actually, but I'm hoping not)...
>
> Trying to load mod_dav_svn.so and mod_authz_svn.so into Apache so I can try
> WebDAV, and I get:
>
> Cannot load /etc/httpd/modules/mod_dav_svn.so into server:
> /etc/httpd/modules/mod_dav_svn.so: undefined symbol: dav_xml_get_cdata
>
> As an experiment, if I comment out the mod_dav_svn.so line in
> conf.d/subversion.conf, so that only mod_authz_svn.so loads, I get:
>
> Cannot load /etc/httpd/modules/mod_authz_svn.so into server:
> /etc/httpd/modules/mod_authz_svn.so: undefined symbol: dav_svn_split_uri
>
> I had to comment out both the mod_dav_svn.so and mod_authz_svn.so lines in
> subversion.conf in order to get Apache to run at all.
>
> Anyone know how I can fix that?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>
>


--
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."

[Eric]

At 01:16 AM 11/8/2006, Mark wrote:

<M>>>>>What linux are you running? It sounds like the mod_dav module
itself is not loaded. You need that to get mod_dav_svn to work :)<<<<<

It's Fedora Core 2.

(Yeah, I know. Old piece of junk. Dont' ask ... can't do anything about
it right now...) :-(

I have "LoadModule dav_module modules/mod_dav.so" in httpd.conf.

How can I tell for sure if it is running?

[Andy Levy]

On 11/8/06, Eric <***@scoot.netis.com> wrote:
> At 01:16 AM 11/8/2006, Mark wrote:
>
> <M>>>>>What linux are you running? It sounds like the mod_dav module
> itself is not loaded. You need that to get mod_dav_svn to work :)<<<<<
>
> It's Fedora Core 2.
>
> (Yeah, I know. Old piece of junk. Dont' ask ... can't do anything about
> it right now...) :-(
>
> I have "LoadModule dav_module modules/mod_dav.so" in httpd.conf.
>
> How can I tell for sure if it is running?

What version of Apache 2 does FC2 come with? You need 2.0.49 minimum.

[Eric]

At 06:52 AM 11/8/2006, Andy Levy wrote:

>>What version of Apache 2 does FC2 come with? You need 2.0.49 minimum.

It's 2.0.49.

[Gundersen, Richard]

We use Eclipse with the Subclipse plugin, which is a good client,
although using it to merge is very confusing - its not very intuitive.
It works, but getting it to generate the svn merge command you expect is
sometimes tricky. At the moment, I use Subclipse for everything except
merging, for which I use the command line because you know exactly what
its doing. And of course this is biased towards Java development.

Richard

-----Original Message-----
From: Eric [mailto:***@scoot.netis.com]
Sent: Wednesday, November 08, 2006 11:56 AM
To: ***@subversion.tigris.org
Subject: Re: Concurrent versioning = spawn of the devil?

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-***@subversion.tigris.org
For additional commands, e-mail: users-***@subversion.tigris.org


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

*** Disclaimer ***

This electronic communication is confidential and for the exclusive use of the addressee. It may contain private and confidential information. The information, attachments and opinions contained in this E-mail are those of its author only and do not necessarily represent those of London Scottish Bank PLC or any other members of the London Scottish Group.

If you are not the intended addressee, you are prohibited from any disclosure, distribution or further copying or use of this communication or the information in it or taking any action in reliance on it. If you have received this communication in error please notify the Information Security Manager at ***@London-Scottish.com as soon as possible and delete the message from all places in your computer where it is stored.

We utilise virus scanning software but we cannot guarantee the security of electronic communications and you are advised to check any attachments for viruses. We do not accept liability for any loss resulting from any corruption or alteration of data or importation of any virus as a result of receiving this electronic communication.

Replies to this E-mail may be monitored for operational or business reasons. London Scottish Bank PLC is regulated by the Financial Services Authority.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.

[Ruslan Sivak]

Gundersen, Richard wrote:
> We use Eclipse with the Subclipse plugin, which is a good client,
> although using it to merge is very confusing - its not very intuitive.
> It works, but getting it to generate the svn merge command you expect is
> sometimes tricky. At the moment, I use Subclipse for everything except
> merging, for which I use the command line because you know exactly what
> its doing. And of course this is biased towards Java development.
>
> Richard
>
We use eclipse with Subclipse as well, and I only learned to do merged
because how easy eclipse makes it. The merge tool it has kind of sucks,
so I set it up to use the tortoisemerge program for conflict resolution,
but otherwise, it's pretty good.

Russ

[Mark Phippard]

Ruslan Sivak <***@istandfor.com> wrote on 11/08/2006 10:29:20 AM:

> Gundersen, Richard wrote:
> > We use Eclipse with the Subclipse plugin, which is a good client,
> > although using it to merge is very confusing - its not very intuitive.
> > It works, but getting it to generate the svn merge command you expect
is
> > sometimes tricky. At the moment, I use Subclipse for everything except
> > merging, for which I use the command line because you know exactly
what
> > its doing. And of course this is biased towards Java development.
> >
> > Richard
> >
> We use eclipse with Subclipse as well, and I only learned to do merged
> because how easy eclipse makes it. The merge tool it has kind of sucks,

> so I set it up to use the tortoisemerge program for conflict resolution,

> but otherwise, it's pretty good.

Subclipse is trying to make the merge process easier, not more difficult.
It follow the same approach as TortoiseSVN. Bring up the dialog, enter
the URL, usually it will be in the drop-down already, then use the Select
button to select the revisions you want to merge. The key is to select
the revisions that you want merged. Do not try to select the numbers you
would enter into the command line, instead select the actual revisions
that contain the changes you want merged. This will then populate the
dialog with the right numbers to merge those revisions.

If you know the numbers you want to use, then just type them in instead of
using the select dialog.

The conflict resolution editor comes from Eclipse. I personally prefer
TortoiseMerge as well, and that is why we made it a preference in
Subclipse to use an external tool for that.

Mark

[Brad Stiles]

> > 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.

Multitudes of developers world-wide, working on thousands of projects, would no doubt disagree. However, this sounds more like "I don't know how to do concurrent versioning and merging, and I don't want to know" than an informed opinion based on experience with both systems.

If he thinks the TortoiseSVN diff/merge utility is too difficult to use, then I don't knwo what he *would* consider easy. That's one of the niftiest tools of it's kinds I've seen, especially at the price!

> He says that we are exposing our clients to too much risk if we
> subject their code to that kind of an environment.

Without robust development practices, such as regularly run programmer, integration and acceptance tests, both schemes are risky.

> 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!".

That sounds like a control [freak] issue, not a risk assessment.

> 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 suggest asking on the TSVN list; someone there might be able to guide you in the right direction. FWIW, TSVN remembers my credentials just fine; we're using LDAP authentication to an Apache hosted repository running on some distro of Linux, I think it's Red Hat EL 4, but I'm not sure.

I can't give you any links to arguments, other than the ones others have provided, but I can give you our experience in moving from PVCS. We had originally chosen PVCS over VSS because of the problems experienced by other users, as well as some evaluation done by our own folks. Given that even Microsoft never used it, we didn't figure it suited us either.

The move from Lock-Modify-Unlock to Copy-Modify-Merge went largely unnoticed, except by those of us who were continuously having to unlock stuff that was left locked by developers on vacation or some such. Simultaneous editing of files in the same branch just doesn't happen all that often, and when it does, it's usually just a matter of a lack of communication.

Merging of branches back to trunk is simple using even the command line interface; with Tortoise, it's ridiculously so. The merge tool in PVCS was, admittedly, pretty good, but TortoiseMerge still beats it, and both of them were far better than the VSS one.

Note that the Lock-Modify-Unlock pattern isn't *always* bad. Used with binary, or otherwise un-mergeable, files, such as some word processing documents or spreadsheets, it can help prevent a lot of wasted effort.

Brad

[Robert Graf-Waczenski]

> Note that the Lock-Modify-Unlock pattern isn't *always* bad.
> Used with binary, or otherwise un-mergeable, files, such as some
> word processing documents or spreadsheets, it can help prevent a
> lot of wasted effort.

True. But don't spread this message without mentioning that
SVN indeed supports this pattern, per "svn:needs-lock", which
prompts the svn client (or was it TortoiseSVN - dunno) to
set/reset the read/only flag on the affected files.

Robert

[Brad Stiles]

> 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...

Of course, there always the coercive course. When we implemented Subversion, it became policy that nothing was built for deployment except what was in the repository. If it wasn't there, it wouldn't be deployed for testing or production, so no building locally and shipping it off to the test guys from your desktop.

Bear in mind that we didn't implement Subversion on a whim; we researched, tested and sought buy-in from the entire IT hierarchy, as well as interested parties outside of development who would be using it.

YMMV vary in that regard. :-)

Brad

[Rob Hubbard]

If you don't like TortoiseMerge, don't like Subclipse merge, and/or don't use Windoze, you might like to try
KDiff3 <http://kdiff3.sourceforge.net/>.

If you're using Tortoise on Windoze, then make a note of your Merge Viewer and Diff Viewer settings before you install KDiff3, or remember to disable integration with Tortoise during installation.

I quite like what I've seen of this tool so far, but have not yet used it in anger on a really big, complex merge. I have tried many other tools, however, including some commercial evaluations, and have not been entirely satisfied with any. KDiff3 looks quite promising, even though it's still pre-1.0 release.

Rob.


> -----Original Message-----
> From: Mark Phippard [mailto:***@softlanding.com]
> Sent: 08 November 2006 15:35
> To: SVN MaillingList
> Subject: Subclipse Merge (was: Concurrent versioning = spawn of the
> devil?)
>
>
> Ruslan Sivak <***@istandfor.com> wrote on 11/08/2006 10:29:20 AM:
>
> > Gundersen, Richard wrote:
> > > We use Eclipse with the Subclipse plugin, which is a good client,
> > > although using it to merge is very confusing - its not
> very intuitive.
> > > It works, but getting it to generate the svn merge
> command you expect
> is
> > > sometimes tricky. At the moment, I use Subclipse for
> everything except
> > > merging, for which I use the command line because you
> know exactly
> what
> > > its doing. And of course this is biased towards Java development.
> > >
> > > Richard
> > >
> > We use eclipse with Subclipse as well, and I only learned
> to do merged
> > because how easy eclipse makes it. The merge tool it has
> kind of sucks,
>
> > so I set it up to use the tortoisemerge program for
> conflict resolution,
>
> > but otherwise, it's pretty good.
>
> Subclipse is trying to make the merge process easier, not
> more difficult.
> It follow the same approach as TortoiseSVN. Bring up the
> dialog, enter
> the URL, usually it will be in the drop-down already, then
> use the Select
> button to select the revisions you want to merge. The key is
> to select
> the revisions that you want merged. Do not try to select the
> numbers you
> would enter into the command line, instead select the actual
> revisions
> that contain the changes you want merged. This will then
> populate the
> dialog with the right numbers to merge those revisions.
>
> If you know the numbers you want to use, then just type them
> in instead of
> using the select dialog.
>
> The conflict resolution editor comes from Eclipse. I
> personally prefer
> TortoiseMerge as well, and that is why we made it a preference in
> Subclipse to use an external tool for that.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org

_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.

This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.

[Eric]

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?

[Les Mikesell]

On Wed, 2006-11-08 at 18:12, Eric 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?

You can tell cvs to check out a single file and it will do it, but
it will insist on creating a new directory to hold it and the CVS
directory it needs internally. It will create directories to
match the path in the repository by default or you can specify
a new one with -d. You can later check out additional files
from the same repository directory into that directory, and
you can commit them back individually.

--
Les Mikesell
***@gmail.com

[Eric]

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.

[Robert Graf-Waczenski]

I hit "Reply" too quickly...

Robert

> -----Original Message-----
> From: Robert Graf-Waczenski [mailto:***@lsoft.com]
> Sent: Donnerstag, 16. November 2006 13:40
> To: Steve O'Hara
> Subject: RE: RE: Subversion vs CVS for document files
>
>
> > 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.
>
> But bashing is fun :-)
>
> No, serious: SourceOffSite licenses cost *extra* money
> whereas the VSS client comes (almost) free with several other M$
> products.
>
> Still your observation is correct: Since all working copies are maintained
> by the SourceOffSite server, the timestamp offset problems don't occur.
>
> Robert

[Rob Hubbard]

Hello Robert, Eric, and everyone,


Here's a situation I've encountered more than once when working with (or rather "against") VSS (in its default "Lock-Modify-Unlock" locking mode):

Alex and Beth both gets the latest version. Alex starts working on File_1, and so locks it; meanwhile Beth starts working on File_2, and so locks that.

Later, Alex finds that he also needs to edit File_2, and Beth finds that she also needs to edit File_1. Thus they are deadlocked, and will have to have a fight out in the car park to decide who is going to surrender their lock.


VSS's other mode, the "multiple checkout mode" is something of hybrid. At first, it seems rather like a "Copy-Modify-Merge" model. However, you soon come to realise that it is no longer "true C-M-M" any more than it is "true L-M-U", hence my term "hybrid".

I have come across a problem even here, again more than once:

Alex and Beth both get the latest version. Alex locks File_3. A little later, Beth makes changes to many files including File_3 and another file, File_4. Now Alex finds that he needs to edit, and therefore lock, File_4. Although he can do this now (whether still locked by Beth for further development or not), his locked version of File_3 not longer compatible with her latest version of File_4. Alex needs Beth's version of File_3 now, and therefore all the other files in the set. (Like labels, locks can only be applied to the latest version of a file, and can't be applied retrospectively to an older version despite the fact that they can be held if they were applied in the past. And of course, with no atomic commits, it is relatively difficult to determine the minimum required set of files to get the latest version of.) Thus Alex will need to unlock File_3, to a (manual?) merge and then relock it.

Thus to use VSS's hybrid model, you really need to lock all the files you might conceivably need to change in advance, and together. The only way to be *sure* that you have locked enough is to lock everything, which is impractical for other reasons. (The view of locks on the database is not of no practical use any more, for example.)


When I proposed migration of my team's sources from VSS to SVN there were some reasons to resist.

With VSS, if you look at the "database", you can see who is working on which files (in whichever locking mode). This can be helpful when deciding upon a range of coding tasks, as you can estimate the complexity of any resulting merge. It's not foolproof, as it obviously doesn't let you see into the future to see which files will be locked by others over the duration of your chosen task.

(Perforce has a command to request editing a file, thus the Perforce approach is similar, but better, than that of VSS; with Perforce you can see the locks across your team, I believe.)

In practice, we have not missed this view of locks. The ability to work on a base from any revision is often useful. The update process seems to run very smoothly, considering that it is essentially a merge. SVN also has the massive advantage that it's the working copy that points to the repository, and not the other way around (setting on the server per user/machine combination as with VSS).

Merging is a pain with either VSS or SVN (or any other VCS for that matter) if branching is not managed carefully. That's another story, really. However, I have found merging much more straightforward with SVN than with VSS. I think locks really come into play when doing a merge. With SVN, a file or directory can still be locked (either with SVN advisory locks, or with a "fascist" commit hook); thus when undertaking a major merge, the target directory, say, of the merge may be locked, which makes the process a little more manageable.

Somewhat off-topic: My personal worry was that in VSS, we used labels very heavily. I was not familiar with the tags approach. SVN does need to be supplemented with scripts to be able, for example, to view a history/log of a file relative to the revisions copied to tags; so it didn't do what I wanted "out of the box". On the other hand, the ability to able to create a tag cheaply and "retrospectively" is an *enormous* benefit.


Rob.

> -----Original Message-----
> From: Robert Graf-Waczenski [mailto:***@lsoft.com]
> Sent: 08 November 2006 08:58
> To: ***@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:***@scoot.netis.com]
> > Sent: Mittwoch, 8. November 2006 07:10
> > To: ***@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-***@subversion.tigris.org
> > For additional commands, e-mail: users-***@subversion.tigris.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org

_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.

This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.

[Steve O'Hara]

In my quest to convert from VSS to svn I've tinkered with the notion
that all shared files have to exist in separate directories which are
then referred to by the externals mechanism.
However, am I right in thinking that if I make a change to a file that
is from an external project, when I commit the changes, the changed
external file will not be submitted to svn automatically?

Thanks,

Steve

[John]

Steve O'Hara wrote:
> In my quest to convert from VSS to svn I've tinkered with the notion
> that all shared files have to exist in separate directories which are
> then referred to by the externals mechanism.
> However, am I right in thinking that if I make a change to a file that
> is from an external project, when I commit the changes, the changed
> external file will not be submitted to svn automatically?
>
> Thanks,
>
> Steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-***@subversion.tigris.org
> For additional commands, e-mail: users-***@subversion.tigris.org
>
>
As I understand it, Steve, you have to commit the externals individually.

For a later feature, what would be involved in allowing externals to be
checked in from the project(s) which use them?

J

[Martin Tomes]

Steve O'Hara wrote:
> In my quest to convert from VSS to svn I've tinkered with the notion
> that all shared files have to exist in separate directories which are
> then referred to by the externals mechanism.
> However, am I right in thinking that if I make a change to a file that
> is from an external project, when I commit the changes, the changed
> external file will not be submitted to svn automatically?

The alternative (and I think better) approach to externals is to use svn
switch to get shared code. Say you have some shared code in
.../shared/libx and you want it in your working copy. Create an empty
folder where you want it and call it libx. Add and commit that folder.
Now do this:

svn switch .../shared/libx libx

Where ... is the rest of the URL. Now you will have libx in your
working copy, updates and commits will happen 'through' the switch. We
create a script at the top level of each project which executes the
switch commands. On most of them adding a -u unswitches them.

--
Martin Tomes
echo 'martin at tomes x org x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'

Visit http://www.subversionary.org/

[Andy Peters]

On Nov 17, 2006, at 4:25 AM, Steve O'Hara wrote:

> In my quest to convert from VSS to svn I've tinkered with the notion
> that all shared files have to exist in separate directories which are
> then referred to by the externals mechanism.
> However, am I right in thinking that if I make a change to a file that
> is from an external project, when I commit the changes, the changed
> external file will not be submitted to svn automatically?

i've found it safer and easier to never use an external that's not a
tag. Everything that's usable as an external is its own project and
maintained as such.

One reason for this that may not be obvious is if you tag a release
of your project, only your project's code is tagged. Say I have an
FPGA design (I'm a hardware guy) that uses a UART module. I include
the UART trunk as an external in my project, and I build my chip and
I'm happy. I tag the project. A couple of months later, a problem
pops up so I check out the tag to see what was used to build the
chip. Unfortunately, someone else has modified the UART module
(maybe added or removed a port or whatever). Since my project uses
the UART module trunk instead of a tag, now my FPGA won't build.

So for this reason I always use tagged versions of external modules.

-a

[Kevin P. Fleming]

Andy Peters wrote:
> So for this reason I always use tagged versions of external modules.

http://svn.digium.com/view/repotools/autotag_externals?rev=94&view=markup

This script can be used to create automatic tags of all your projects
brought in via svn:externals, so that you can develop against 'trunk' or
a branch and yet still have a proper snapshot when you create a tag of
the project that references the externals.

[Toby Johnson]

Steve O'Hara wrote:
> In my quest to convert from VSS to svn I've tinkered with the notion
> that all shared files have to exist in separate directories which are
> then referred to by the externals mechanism.
> However, am I right in thinking that if I make a change to a file that
> is from an external project, when I commit the changes, the changed
> external file will not be submitted to svn automatically?
>

It depends on which Subversion client you're using. The command-line
client does not automatically process externals on commits (although it
does on "status"), but TortoiseSVN does by default.