views:

41

answers:

5

At SourceSafe, I can know if someone modified a file but dont commited, because file will be locked.

By default Svn don´t work with locks, it´s good, but how can I know if someone modified any file and forgot to commit?

At my work, we compile dlls at development machine and send to staging, I know that build server integrated with subversion server resolve this problem, but I dont want do this at moment.

Thanks

PS:My concern is to compile a project with old .cs, because the programmer may not have made the commit.

+4  A: 

That's not how SVN works.

SubVersion uses the edit-merge-commit way of source-control. Anyone is free to change any file. When committing, if there is a conflict, the changes can be merged (automatically or manually)

More discussion about locking and edit-merge-commit can be found here:

http://stackoverflow.com/questions/998581/vss-to-subversion

Philippe Leybaert
*"Anyone is free to change any file."* - not strictly correct. **Since v1.2, Subversion has optionally supported locking** ("reserved checkouts"). More info here: http://subversion.tigris.org/svn_1.2_releasenotes.html. Many users feel, however, that this is against the philosophy of Subversion, and is only included for completeness.
RedFilter
My concern is to compile a project with old .cs, because the programmer may not have made the commit.
Fujiy
A: 

There is a Check For Modifications command that you could run after an Update, unless I am misunderstanding you.

Josh Stodola
It sounds like he's looking for a way to tell if other developers have modified a file locally, but haven't committed back to SVN yet. So Check For Modifications doesn't quite fit the bill.
Agent_9191
+1  A: 

you could make an internal procedure where everybody before he starts modifying a file he asks the SVN server for a lock. That way everybody receives an update that he is working on that file.

But that would kind of remove the benefit of Subversion where more people could work on same file at the same time, and merge the result.

solomongaby
A: 

That style of deployment isn't going to work well with Subversion. You stated you don't want to put a build server in place yet, so you're going to have to rely on all the developers to perform a consistent set of steps prior to deploying so that nothing is missed when sent to staging. How I'd tackle this is create a build script that would perform the following actions (only for publishing to staging):

  • Pull down the latest from Subversion
  • Build all output
  • Run unit tests
  • Commit the all modifications files back to SVN
  • Push the assemblies to staging
  • Post-push configuration changes/environment readiness

This way uncommitted changes won't exist in whatever is out in staging.

Agent_9191
A: 

You can use svn status to check if you have any local uncommited changes.

To know if anyone has some uncommited changes you would need to persuade/bribe/pay/scare others to run the the test everyday, or put it in cron or other scheduler. Of course then you would be alarmed about files that they left ucommited for a reason (ex. something not yet finished, not working properly, etc).

silk
How I use svn status with Tortoise SVN? It scan all my hd or just selected project?And yes, we have versioning problems with SourceSafe, imagine with Svn
Fujiy