Greetings, Eric B.!
> Hmmm ... not sure I understand this concept entirely. I basically use a CVS
> tag every time I do a build or a release to "mark" the version of all files
> required for that particular build. 99% of the time, this tag is a one time
> thing. However, it does happen every-so-often that a build fails b/c
> someone forgot to check in a file. So instead of giving it a new build
> number once the file is committed, I just retag with the same tag name and
> perform the build. Would that concept/workflow cause problems in SVN?
This is much less likely to happen with Subversion in general. As I said, each
revision slicing the *whole repository* at a certain moment of time, which is
supposed to be a complete and functional state. Yep, it's not certainly true,
but since it is a complete state, you can always tell that "in this state a
building process fails due to this issue, guys - get to work and resolve it".
At the time you see a revision worth branching to the /release, you run last
checks over it and if it is suitable, you "tag" this revision to appropriate
place in repository. It does not need a floating tags to continue your work
tomorrow, the revision umber already has this function for you. Even if there
was commits after the desired revision, you can still refer to the desired
revision and finish your work in one way or another.
> Secondly, I'm a bit confused with the concept of version numbers in svn
> overall. I understand that a version relates to the state of the overall
> project - not any individual file as in CVS. So if I am working in a
> specific file, and want to see a previous version of that file, does that
> require the client to download the entire code repository of a previous
> version?
Absolutely, no.
Just ask server about changes made to the file and you can see in which
revisions it was touched in which way.
If you just want to compare HEAD version to previous state, you can use
revision ranges to retrieve previous version of the file.
> In CVS, since files are versioned independently, I can easily see
> the state of any one file throughout its history, and retreive a particular
> revision for that one file and stick with it (ie: sticky tags). Does that
> concept still hold true for svn?
Not directly, but it's still possible to track revisions in which file was
modified or in any way affected.
However, you can't put your changes in before the HEAD.
--
WBR,
Andrey Repin (anrdaemon_at_freemail.ru) 10.09.2009, <21:22>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393377
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-10 19:35:58 CEST