Skip to content

Settings and activity

5 results found

  1. 65 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    15 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Kamil Andrzejewski commented  · 

    That would be perfectly acceptable indeed. Knowing the file has been already checked out and cannot be checked-in but can still be locally modified.

    An error occurred while saving the comment
    Kamil Andrzejewski commented  · 

    I disagree, this makes it impossible for someone to just open a Unity scene (for example), change something to test and move on by undo-ing the work.

    An error occurred while saving the comment
    Kamil Andrzejewski commented  · 

    Both your proposition make it so that you cannot check-in the file nor version it. That is not the goal.

    The user needs to be able to control which types of files can only have 1 unlocked, latest revision, independent of the branch.

    Not "one" revision, or no revision (local)

    An error occurred while saving the comment
    Kamil Andrzejewski commented  · 

    psantosl,

    Well, basically what you're describing is not locking, what you're describing is that you don't want the file to be branched at all, correct??
    - No. You still want the user to be able to work on the file while being in a branch. The file will never be merge as only the latest change-set will be unlocked.

    The best example is with .unity scenes; the user will save and modify the scene to do its work BUT it doesn't mean he has to commit it. This is very different from working on a .max as its a given that any changes you save, you'll commit it. This is not the case with scenes where you need to save and modify the scene in order to implement other changes.

    An error occurred while saving the comment
    Kamil Andrzejewski commented  · 

    In other words:
    - Once changed, a file is automatically exclusively checkout for all users
    - Even after "Checking-in", it is still locked for everyone who is not on the same branch
    - Only the latest, on the same branch, checked-in version of the file can ever be modified

    Kamil Andrzejewski shared this idea  · 
  2. 62 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Kamil Andrzejewski commented  · 

    This will eventually lead to patch, so it is definitely a requirement.

    Kamil Andrzejewski supported this idea  · 
  3. 175 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    20 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kamil Andrzejewski supported this idea  · 
  4. 102 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kamil Andrzejewski supported this idea  · 
  5. 35 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Kamil Andrzejewski supported this idea  ·