Sun 06 Aug 2006 03:28:07 AM UTC, comment #4:
>>If I apply a more liberal default branch like
>> net.venge.* I accidently push already anything for nvm.guitone
>> if I fix a translation.
>
> Why is it an accident? Were you planning to keep those revisions secret? :-)
No, of course not =) But I'd like to follow the approach "only working code in the repository. While each changeset / revision can obviously be updated later on, I at least want to make the recent head stable. If I commit subsequent revisions A, B and C, and only C is stable (because A and B have been partial commits on some of the changed files), I do not want to accidently push A and B without C. Because C is what any other user should see as next head, not A or B.
> If what you're doing is that you really have two
> projects you work on, and you don't want to
> spend time pulling stuff for one when you're
> working on the other... then why not have two
> databases, one for each project?
Well, umm... laziness? Ok, Can't answer anything better here. You're right, two databases would be the solution for this case.
But still, if I only work on one project (like monotone), and the branch setup is halfway decent (main branch A, sub branches A.something, but not B, so a branch pattern A* would catch them all), A* is still a lot of stuff to pull. I mean, I'm in the lucky position to not to be on 56k (obvious I was many years), but I guess still many users are on 56k in the US and it might be an issue for them. Ok, one could always do
$ mtn pull SERVER BRANCH_PATTERN
but then again... if I am in the workspace context and I can already skip the --db option (since this is read out from the workspace options), why can't I skip SERVER and BRANCH_PATTERN as well and can safely assume that those are used which are noted in the workspace and not those which are somewhere noted in the db and not entirely obvious to view/modify (see my rant on mtn ls vars...)?
|
Sat 05 Aug 2006 08:05:09 AM UTC, comment #3:
> See, for me its the other way around. I'm working on nvm.guitone > and nvm. Both projects use the same db, but different workspaces
> obviously. If I apply a more liberal default branch like
> net.venge.* I accidently push already anything for nvm.guitone
> if I fix a translation.
Why is it an accident? Were you planning to keep those revisions secret? :-)
> A major thing why a very liberal default branch isn't right for
> many users IMHO is that this pulls too much from the server
If you don't actually want the stuff from the server, then you probably shouldn't pull it in the first place.
If what you're doing is that you really have two projects you work on, and you don't want to spend time pulling stuff for one when you're working on the other... then why not have two databases, one for each project?
|
Mon 31 Jul 2006 08:55:50 AM UTC, comment #2:
> you don't accidentally forget to push things, [...]
> I recommend making your default netsync pattern more
> liberal
See, for me its the other way around. I'm working on nvm.guitone and nvm. Both projects use the same db, but different workspaces obviously. If I apply a more liberal default branch like net.venge.* I accidently push already anything for nvm.guitone if I fix a translation. But this is only a minor.
A major thing why a very liberal default branch isn't right for many users IMHO is that this pulls too much from the server, and this is especially painful since
a) these users could be on dial-up and therefor do not want every possible branch
b) it still takes ages with mtn and decent medium hardware to pull revisions (if it would be a couple of seconds, no problem, but it still takes minutes to, e.g. pull 100 revisions and their certs for me)
> Regarding db options, see "mtn ls vars", "mtn set".
> (Maybe they should be under "mtn db", dunno.)
Hrm... there is a mtn set and mtn unset, but no mtn get. However, there is a mtn attr set and mtn attr get, what does that tell us...? =)
|
Mon 31 Jul 2006 07:37:33 AM UTC, comment #1:
The problem with this is that push/pull/sync are database operations; it is inconsistent to have them act totally differently when run in a workspace... and most users (e.g., me ;-)) definitely don't want to just sync a single branch, even when they run in a workspace.
It is also an intentional design point that you normally sync the whole project at a time, because it means there is only one command to execute to get synced up, you don't accidentally forget to push things, etc.
I recommend making your default netsync pattern more liberal, and putting revisions that you're unsure of on branches instead of sequestering them in your local db. This is the workflow monotone is designed to support best, since, well, we think it's going to end up working the best anyway, so no point in pulling it down to other workflows's level...
Regarding db options, see "mtn ls vars", "mtn set". (Maybe they should be under "mtn db", dunno.)
|
Mon 31 Jul 2006 07:19:49 AM UTC, original submission:
I often stumbled across the problem that I just committed my work and wanted to push it upwards, however nothing was pushed since the db default was set to another branch. I'd find it more intuitive if push/pull/sync would use the server/branch of the current workspace if they're executed in such, and just use the db default options outside of a workspace.
Also, in this regard it would be nice to set/view the db options via a separate command under 'mtn db' rather then needing to call push/pull/sync with --set-default.
|